By: Security learner (based on real disclosure)

🧠 What I studied

This write-up is based on a real vulnerability report I found on HackerOne: Report #3591956.I'm sharing this as part of my learning journey in security research — all credit to the original reporter and the curl team.

🧃 The bug in one sentence

If you tell curl to fetch two different SMB files from the same server, it might crash because it tries to read memory that was already freed — a Use-After-Free.

🧸 Let's make it super simple

Imagine you borrow a sticky note from your friend's desk (that's req->path pointing into smbc->share).

Then you return the whole desk to your friend (that's free(smbc->share)).

But later, you still try to read what's on that sticky note (that's strlen(req->path)).

  • The note is gone.
  • The desk might now hold someone else's stuff.
  • Result? Confusion → crash → maybe worse.

That's exactly what happens in curl's SMB code.

🧩 Technical bits (simplified)

What's happening behind the scenes

  1. curl parses the first SMB URL like
  2. smb://server/share1/file1
  3. → it creates a connection object and stores "share1\\0file1\\0".
  4. → req->path just points to "file1" inside that storage.
  5. When you give a second URL with the same server but different share:
  6. smb://server/share2/file2
  7. → curl reuses the connection (good for speed).
  8. → But in the process, it frees the old connection's storage that req->path still points to!
  9. Later, when sending the SMB request
  10. → strlen(req->path) tries to read the now-freed memory.
  11. → Boom — ASAN screams: heap-use-after-free.

⚠️ Why should we care?

  • Crash (DoS) — an app using libcurl could just die.
  • Info leak — the freed memory might get reused for something else (like a password or crypto key), and a strlen() read could expose it.
  • Potential code execution — if an attacker can control what fills that freed memory before the read, they might trick curl into doing bad things.

And the scariest part?

You don't even need a real SMB server. A fake one, or just two URLs in one command, can trigger this.

🛠 How to reproduce (the boring but useful version)

bash

# Build curl with ASAN & SMB
./configure --with-openssl --enable-smb
make CFLAGS="-fsanitize=address -g" LDFLAGS="-fsanitize=address"
# Run a fake SMB server (provided by reporter)
python3 fake_smb_server.py 5445
# Trigger the bug
./src/.libs/curl -u guest:guest \\
  "smb://127.0.0.1:5445/share1/file1" -o /dev/null \\
  "smb://127.0.0.1:5445/share2/file2" -o /dev/null

ASAN will print a colorful "heap-use-after-free" error.

🩹 How to fix (conceptually)

Make req->path independent – copy the string instead of just pointing into connection-owned memory.

Or, when connection is freed, set all related request pointers to NULL.

🙌 Final thoughts — as a learner

I learned this from HackerOne report #3591956. Huge thanks to the reporter and the curl team. Even curl — a tool millions use — can have simple but dangerous memory bugs. That's why we need automated testing (fuzzing, ASAN) and manual reviews. Never assume software is bulletproof.

🔗 References