DF-0673 — nbssn_recv (smb_trantcp.c) mbuf leak on receive error / partial chain

Verdict

SOURCE-CONFIRMED (not live-testable here). The bug is unambiguous in source; the live trigger requires a malicious SMB server speaking NetBIOS Session Service + enough SMB to advance the kernel SMB client into the post-negotiate receive loop, which is beyond what this guest's mount_smbfs + a minimal fake server could drive in the available time (the trigger hangs in mount_smbfs waiting on smbiod before reaching the leak site).

Mechanism

sys/netproto/smb/smb_trantcp.c:313-376 nbssn_recv:

Two distinct leak paths, both rooted in sbinit() only zeroing fields (sys/sys/sockbuf.h:115-126) — it never frees the prior sb_mb chain:

Path 1 — inner do/while re-iteration orphans a partial chain

do {
    sbinit(&sio, savelen);   // :346 ZEROES sio.sb_mb without freeing it
    rcvflg = MSG_WAITALL;
    error = so_pru_soreceive(so, NULL, NULL, &sio, NULL, &rcvflg);
} while (error == EWOULDBLOCK || error == EINTR || error == ERESTART);

If so_pru_soreceive returns EWOULDBLOCK/EINTR/ERESTART having already moved some bytes into sio.sb_mb (which happens with MSG_WAITALL on a slow/interrupted TCP receive), the next loop iteration's sbinit(&sio, savelen) zeroes sio.sb_mb — orphaning (leaking) the prior partial chain.

Path 2 — outer-loop if (error) break; skips cleanup

if (error)           // :352-353
    break;           // *** exits outer loop ***
...
if (error == 0) {    // :367  <-- cleanup only runs on success
    if (mpp) *mpp = sio.sb_mb;
    else      m_freem(sio.sb_mb);
    ...
}

Any non-retry receive error (e.g. ECONNRESET after a TCP RST) leaves a partial sio.sb_mb chain that the success-only cleanup never frees.

Reachability

• nbssn_recv is called from smb_nbst_recv (smb_trantcp.c:539), the SMB_TRAN_RECV vector, invoked in a for(;;) loop by smb_iod_recvall (smb_iod.c:304,322-324). Each iteration that errors out and re-enters can re-leak.
• Sustained attack (a malicious SMB server that keeps accepting connections and RST'ing mid-stream) drives mbuf-pool exhaustion → network collapse / panic.

Threat model / preconditions (realistic)

• smbfs.ko loaded (root action; realistic on systems that mount SMB shares).
• A malicious SMB server the victim mounts from (network attacker / MitM / compromised server).

No kldload by the attacker; the trigger is the kernel SMB client processing untrusted server data.

Why not live-reproduced here

The fake-server PoC in fake_smb_server.c completes the NBSS session-request handshake and emits a malformed SMB negotiate response, then sends a NBSS message header claiming 4000 B but delivers only 50 B before RST'ing. The intent was to drive mount_smbfs into the nbssn_recv post-negotiate path. In practice mount_smbfs hangs in D1 (uninterruptible wait) before reaching the leak site — smbiod blocks waiting on the bogus negotiate response that the minimal fake server never properly formats, so the kernel never advances to nbssn_recv for the post-negotiate message. A live PoC would require a fully-conforming NBSS+SMB negotiate response (correct SMB1 header, dialect array, security blob, etc.) — substantial additional work beyond this run's budget.

The bug itself is unambiguous: sbinit() does not free, and the error paths skip m_freem(sio.sb_mb). Source confidence is certain.

Realistic impact ceiling

This is an mbuf-pool exhaustion DoS (resource leak). It is not a memory-corruption primitive — no attacker-controlled write, no UAF, no type confusion — so there is no escalation chain. Ceiling: repeated mounts from a malicious server eventually exhaust the mbuf pool → network collapse / panic.

Fix

sys/netproto/smb/smb_trantcp.c: - Free sio.sb_mb before sbinit(&sio, savelen) in the inner do/while (Path 1). - Free sio.sb_mb on the if (error) break; outer-loop exit (Path 2). - Free sio.sb_mb on the ECONNRESET outer-loop exit (the so->so_state & SS_ISDISCONNECTING|… path) — same class of leak.

See fix.diff (git-apply-able, applies cleanly, compiles, kernel boots).

Fix validation (Phase 8)

fix_status: not_testable. The fix.diff applies (patch -p1 succeeds, git apply --check succeeds) and compiles as part of the single-fix-combined kernel (6.5-DEVELOPMENT #1 built and booted successfully, see DF-0680 evidence pack for the combined build log). But because the live trigger is not reproducible on this guest (see above), the before/after leak behavior cannot be measured here. The change is small, mechanical, and obviously correct given the source-level analysis.