DF-0627 PoC — mbuf leak on duplicate SMB responses

Build

No client binary to build — the trigger is a malicious SMB server (network attacker position) plus a victim that mounts its share. build.sh is a no-op placeholder.

Run / trigger (requires the malicious-server harness)

1. Run a malicious SMB1 server reachable from the guest.
2. Victim mounts the share: mount_smbfs //user@evil/share /mnt and issues any request that produces an outstanding MID (e.g. touch /mnt/x).
3. Server sends ONE valid reply for that MID, then a burst of K additional NetBIOS-framed SMB messages with the SAME MID.
4. Observe the leak: ssh dfbsd 'netstat -m' — mbuf count climbs by K (each up to 128 KB). Sustained flooding → mbuf/memory exhaustion → panic.

Expected (bug present)

netstat -m mbuf/memory use climbs monotonically with each duplicate; eventually the kernel panics on mbuf exhaustion.

Expected (FIXED)

Each duplicate's mbuf chain is freed in the else branch; netstat -m stays flat.

Proof

The bug is proven by source tracing in VERDICT.md (the else branch at smb_iod.c:363-366 breaks without freeing m, and the post-loop m_freem at :377 is gated on rqp==NULL which is false after a match).

DF-0627 — mbuf chain leak on duplicate SMB responses (remote DoS)

Verdict

CONFIRMED by exhaustive source tracing — memory leak / remote DoS. Not exercised at runtime in this evidence pack because the trigger requires a malicious SMB server (network-attacker position); the leak is unambiguous in the code.

Mechanism (cited)

sys/netproto/smb/smb_iod.c smb_iod_recvall() (:322-379): - :324 SMB_TRAN_RECV(vcp, &m, td) receives an mbuf chain m from the network. - :354 TAILQ_FOREACH(rqp, ...) finds the outstanding request matching the response MID. - :358-359 first response: md_initm(&rqp->sr_rp, m) — ownership of m transfers to the request (md_top = m, sys/kern/libmchain/subr_mchain.c:319). - :361-362 multipacket: md_append_record(&rqp->sr_rp, m) — ownership transfers. - :363-366 duplicate response (same MID, md_top already set, not SMBR_MULTIPACKET): the else branch does SMBRQ_SUNLOCK(rqp); SMBERROR("duplicate response ..."); break; — it breaks out of the loop without calling md_initm/md_append_record AND without m_freem(m). m is neither attached nor freed. - :374-377 the only post-loop m_freem(m) is gated on if (rqp == NULL) — but rqp is non-NULL (it matched at :355), so m_freem is SKIPPED. - Next loop iteration :323 m = NULL; then :324 overwrites m; the orphaned chain is permanently leaked.

md_initm ownership claim: sys/kern/libmchain/subr_mchain.c:316-319 mdp->md_top = mdp->md_cur = m;. SMB_MAXPKTLEN = 0x1FFFF (sys/netproto/smb/smb.h:292); nbssn_recv (smb_trantcp.c:313) returns each NetBIOS session message as a separate chain, bounded by :305.

Threat model / impact

• Attacker = the SMB server the victim client is connected to (network position; authenticated session sufficient). UI:R — a local user must mount the attacker's share.
• Trigger: server sends one valid reply for an outstanding MID, then K additional NetBIOS-framed SMB messages with the SAME MID. Each duplicate hits :363 and leaks its chain (up to 128 KB). Sustained flooding → mbuf/memory exhaustion → panic/OOM.
• Impact: remote kernel memory-exhaustion DoS (CWE-401). Pure resource leak; no memory corruption, no privilege boundary crossed → no uid0 path.

Why no runtime run here

Reproducing requires a malicious SMB1 server (NEGOTIATE + SESSION_SETUP + TREE_CONNECT + the duplicate flood). That harness is out of scope for this evidence pack; the bug is proven line-by-line above. netstat -m on a victim under attack would show the mbuf count climbing monotonically per duplicate.

Fix

fix.diff adds m_freem(m) in the duplicate else branch before break, so every received chain is either attached (md_initm/md_append_record) or freed. Matches the finding markdown's recommended fix exactly.