DF-2905 — md_done() leaks all pending m_nextpkt records of an mdchain

File: sys/kern/libmchain/subr_mchain.c (md_done, :323-330; md_append_record/md_next_record, :336-369) Severity: High · Class: resource leak → remote memory-exhaustion DoS · Bucket: legacy (only consumer: sys/netproto/smb/, netsmb/smbfs)

What the bug is

md_done() tears down an mdchain with m_freem(md_top). On DragonFly, m_free() follows only m->m_next (sys/kern/uipc_mbuf.c:1320) and even prints mfree: m->m_nextpkt != NULL when the mbuf being freed still has a record link (:1334-1339) — but it does not free the m_nextpkt list. Whenever an mdchain has records appended via md_append_record() and md_done() runs before every record was consumed through md_next_record(), every remaining record chain is orphaned: a permanent, attacker-sized mbuf leak.

In-tree reachability (malicious SMB server → root-mounted smbfs client):

• smb_iod_recvall (sys/netproto/smb/smb_iod.c:353-372) attaches every same-MID NetBIOS message of a SMBR_MULTIPACKET request as a new record (md_initm/md_append_record), draining the socket in one loop before the requester thread wakes.
• smb_t2_reply (sys/netproto/smb/smb_rq.c:474-545) breaks out of its record loop on success (:531-534) or on any parse error, without consuming remaining records; smb_t2_request_int then calls smb_rq_done → md_done(&rqp->sr_rp) (smb_rq.c:741-743, 149) — all still-attached records leak.
• smb_rq_new (smb_rq.c:115-116) re-inits sr_rp with md_done on request reuse — same leak on the retry path.

Each leaked record is a full server-controlled message up to SMB_MAXPKTLEN (0x1FFFF = 128 KiB, sys/netproto/smb/smb.h:292). A sustained flood of extra same-MID responses exhausts the mbuf/cluster pools (kern.ipc.nmbclusters) → system-wide networking DoS/panic. Same threat model as pass-1 finding DF-0627 (duplicate-response leak in smb_iod.c), but a different defect and trigger: unconsumed record tails at md_done(), in the mchain library itself.

How to reproduce (single-tenant QEMU guest, root)

# host: pack transferred to guest /root/df2905
ssh dfbsd   # (vm.sh's ssh config; see dfbsd-qemu/)
cd /root/df2905
sh build.sh          # builds mbread + 4 KLD variants (base/fix x tail/walk)
sh run.sh            # measures live mbufs (mbstat.m_mbufs) around each kldload

Expected on stock (vulnerable) subr_mchain.c:

• RESULT baseline-tail: delta=+8 (3 records x 4 mbufs; md_done frees only record 1; ±1 mbuf noise from the ssh session itself)
• kernel console shows mfree: m->m_nextpkt != NULL with a backtrace whose innermost frames are md_done() → m_freem() — the kernel's own mbuf layer flagging the orphaned record list (see mfree_backtrace.txt)
• RESULT baseline-walk: delta=0 — walking via md_next_record() frees each record correctly (the leak is only at terminal md_done)

Expected on the fixed copy (subr_mchain_fixed.c, generated from fix.diff):

• RESULT fixed-tail: delta=0 — leak gone
• RESULT fixed-walk: delta=0 with identical rc/md_top sequence — record walking semantics preserved, no double-free

Files

• mchain_leak.c KLD test module (compiles the real subr_mchain.c in; stock GENERIC has no libmchain symbols, no clash)
• mbread.c userland reader of kern.ipc.mbstat (m_mbufs is first member)
• Makefile KLD makefile (mode via generated walkflag.h)
• build.sh, run.sh exact guest commands
• run.log, run.2.log decisive runs (incl. 3x stress matrix)
• mfree_backtrace.txt in-kernel evidence of the orphaned nextpkt list
• env.txt guest identity
• fix.diff git-apply-able fix (never applied to sys/)
• VERDICT.md, manifest.json, verdict.json verdict record

VERDICT — DF-2905

Status: reproduced · Impact: dos (remote mbuf-pool exhaustion; memory-safety class: permanent kernel heap leak, not corruption) · Confidence: certain

What was run

Guest: DragonFly dfbsd 6.5-DEVELOPMENT #0 (X86_64_GENERIC, INVARIANTS stock), uname -a in env.txt. The real sys/kern/libmchain/subr_mchain.c was compiled into a KLD (mchain_leak.c) — verified byte-identical to the audited tree (sha256 prefix aa1bf6c02603854c on host and in the guest build dir). The module:

1. TAILTEST — builds an mdchain of 3 records (each a 4-mbuf chain), attaches records 2 and 3 with md_append_record(), then calls md_done() and measures mbstat.m_mbufs (exact live-mbuf counter: incremented in updatestats() uipc_mbuf.c:1001, decremented in m_free() :1447).
2. WALKTEST — same topology, then md_next_record() ×3 (expect rc 0,0,ENOENT and md_top == rec2,rec3,NULL) + md_done(); must free everything on both vulnerable and fixed code (guards the fix against breaking walk semantics or double-freeing).

Result

Cumulative: netstat -m went from 7 → 55 mbufs in use after 6 vulnerable module loads (6 × 8 = 48 leaked) while fixed loads leaked exactly 0.

Independent in-kernel evidence: every vulnerable md_done() emits

mfree: m->m_nextpkt != NULL
Trace ... md_done() at md_done+0x1c <- m_freem() <- md_done() ...

(mfree_backtrace.txt) — the mbuf layer's own warning that a record list is being orphaned, with the backtrace pointing at md_done().

Why this is exploitable (reachability trace, code-only but complete)

• sys/kern/uipc_mbuf.c:1320 — m_free() returns/frees only m->m_next; m_nextpkt chains are never followed by m_freem().
• sys/netproto/smb/smb_iod.c:353-372 — iod receive loop attaches every same-MID message of a SMBR_MULTIPACKET request as an mdchain record (md_append_record), typically several within one recvall pass, before the requesting thread resumes.
• sys/netproto/smb/smb_rq.c:474-545 (smb_t2_reply) exits its record loop on success (:531-534) or first parse error without draining remaining records; :741-743 → smb_rq_done (:146-153) → md_done(&rqp->sr_rp) frees only the current record; the rest leak. Retry path smb_rq_new (:115-116) leaks the same way.
• Attacker = malicious/compromised SMB server; victim = kernel that mounted its share (/dev/nsmb is 0600, so the local user must be root to set up, but the remote server needs no authentication beyond the session — it simply appends extra same-MID responses to a TRANS2 exchange, each up to SMB_MAXPKTLEN = 128 KiB of attacker-chosen size (smb.h:292, framing bound in smb_trantcp.c:305).
• Impact ceiling: unbounded mbuf/cluster consumption → kern.ipc.nmbclusters exhaustion → network stack starvation / kernel OOM conditions. Deterministic per-response leak of up to ~128 KiB mbufs; repeatable at line rate.

Distinct from pass-1 DF-0627 (leak of a dropped duplicate chain in smb_iod.c:363-366): DF-2905 is the library-level record-tail leak at md_done(); DF-0627's one-line fix in smb_iod.c does not cover it.

Fix validation

fix.diff (authored post-verification, never applied to sys/):

• md_done() walks the whole m_nextpkt record list and frees each record with m_freem(); also clears md_cur (hardening for DF-2907).
• md_next_record() detaches the retired record (md_top->m_nextpkt = NULL) before md_done() so the promoted record is not double-freed.

Built as build_fix_*/mchainleak.ko against the same guest: tail delta 0, walk semantics identical (rc 0,0,ENOENT; md_top sequence unchanged), no double-free, module loads/unloads cleanly. All md_done() call sites were audited (smb_trantcp.c:272, smb_rq.c:116,149,417-418,747-748) — none rely on partial-free semantics, and record chains only ever carry nextpkt on sr_rp.

Module-level A/B was chosen over a full nativekernel rebuild because the defect is confined to this file and the harness links the identical source into both variants — a controlled experiment with the same allocator, counters and call path. Baseline and patched behaviors differ exactly on the defect.

Not reproducible / out of scope here

• Turning the leak into memory corruption: none — this is a pure leak.
• The full malicious-SMB-server end-to-end (needs a fake SMB1 server and a mounted share; reachability established by code trace above, guest test proves the library defect deterministically at the exact md_done() call the smb paths invoke).