DF-0598 — PoC: smb_sm_lookupint VC refcount leak

Privileged local DoS (memory-exhaustion + kernel-thread hang) in the DragonFlyBSD in-kernel SMB client. Each failing SMBIOC_LOOKUP-style operation leaks one VC reference via the stale post-loop vcp at sys/netproto/smb/smb_conn.c:175-178. Repeat to bump co_usecount unboundedly on a victim VC (the VC can then never be freed, and a closer racing with teardown hangs forever in smb_co_gone at smb_conn.c:263-265).

The vulnerable code is optional netsmb and is not compiled into the audited X86_64_GENERIC kernel; it ships as the loadable smbfs.ko KLD (which builds & loads cleanly on this guest, creating /dev/nsmb mode 0700 root). See VERDICT.md for the full reachability analysis. This PoC is a code-level proof (mirrors the DF-0265 latent-config precedent) backed by disassembly of the actual shipped KLD proving the compiler retained the stale-write leak.

Files

• leak.c — userspace harness replicating smb_sm_lookupint line-for-line (vulnerable + fixed variants) with a 3-VC driver.
• fix.diff — git apply-able two-hunk fix (validated: KLD builds + loads, disasm confirms the leak is closed).
• VERDICT.md — full narrative + Phase 8 fix-validation results.
• manifest.json — machine-readable artifact catalog.
• Logs: build.log, run.log (N=10), run.1000.log (N=1000), fix_build.log, fix_build_unpatched.log, unpatched.dis, patched.dis, leak_sample.txt, env.txt.

Build & run

./build.sh
./run.sh           # default 10 failing lookups
./run.sh 1000      # stress: linear leak at scale

Expected output

=== VULNERABLE smb_sm_lookupint ===
  call #0: rc=1 (lookup FAILED), but *vcpp=alice@a (NOT NULL!)
  after 10 failed lookups:
    usecount[alice@a] = 11  (baseline 1, delta +10)   <-- 10 refs LEAKED
    ...
=== FIXED smb_sm_lookupint (fix.diff applied) ===
  after 10 failed lookups:
    TOTAL leaked refs across all VCs = 0               <-- leak CLOSED

At N=1000 the vulnerable variant leaks exactly +1000 refs (linear); the fixed variant leaks 0 at any N. See VERDICT.md §4 for the compiled-KLD disassembly proof that the unpatched smbfs.ko actually contains the leak (je 1fa0 → callq smb_co_ref on stale %r14) while the patched KLD does not (je 1fa6 → epilogue).

In-kernel reproduction (requires an SMB server, not available on this guest)

The harness proves the C-level logic. To reproduce end-to-end in the kernel: stand up an SMB server reachable from the guest, load smbfs.ko, mount the share once via mount_smbfs (to populate the vclist), then loop ioctl(fd, SMBIOC_LOOKUP, ...) with a non-matching username and watch the victim VC's co_usecount climb via vmstat -m / a net.smb.treedump sysctl.

DF-0598 — Verdict: REPRODUCED (latent on the audited kernel config); fix VALIDATED

Verdict: REPRODUCED — the stale-vcp reference leak in sys/netproto/smb/smb_conn.c:smb_sm_lookupint (lines 123-180) is real. It is confirmed three ways: (1) line-by-line source trace, (2) a userspace harness that replicates the function verbatim and shows N failing lookups → N leaked refs on the wrong VC, deterministically, and (3) disassembly of the actual shipped smbfs.ko KLD proving the compiler did NOT optimize the stale-write away — the unpatched object code takes smb_co_ref() on the last-visited VC on every list-exhausting miss, while the patched object code skips the ref block entirely on a miss. The bug is latent on the audited X86_64_GENERIC kernel because netproto/smb/* is optional netsmb and is not compiled in; it ships as the loadable smbfs.ko KLD, which builds & loads cleanly on this guest and creates /dev/nsmb (mode 0700 root). An operator who loads smbfs (the only way to use mount_smbfs / the in-kernel SMB client) makes the bug live. (Mirrors the DF-0265 latent-config precedent.)

1. The bug, line by line

smb_sm_lookupint (sys/netproto/smb/smb_conn.c:123-180) walks the global vclist looking for a VC matching vcspec. Its loop variable discipline is broken:

123: static int
124: smb_sm_lookupint(struct smb_vcspec *vcspec, struct smb_sharespec *shspec,
125:     struct smb_cred *scred, struct smb_vc **vcpp)
126: {
127:     struct smb_connobj *scp;
128:     struct smb_vc *vcp;
...
134:     vcp = NULL;                                   <-- init
135:     SMBCO_FOREACH(scp, &smb_vclist) {
136:         vcp = (struct smb_vc *)scp;               <-- STALE WRITE inside body
137:         error = smb_vc_lock(vcp, LK_EXCLUSIVE);
138:         if (error)
139:             continue;                             <-- vcp retains value
...
145:             goto unlock;                          <-- every miss
...
171:         break;                                    <-- only success
172: unlock:
173:         smb_vc_unlock(vcp, 0);                    <-- no `vcp = NULL;` here
174:     }
175:     if (vcp) {                                    <-- fires on STALE vcp
176:         smb_vc_ref(vcp);                          <-- LEAK: ref on wrong VC
177:         *vcpp = vcp;                              <-- wrong VC returned
178:     }
179:     return error;
180: }

SMBCO_FOREACH is SLIST_FOREACH((var), &(cp)->co_children, co_next) (smb_conn.h:223). SLIST_FOREACH only writes var (here scp) at the loop condition; the body's assignment vcp = (struct smb_vc *)scp; at line 136 is therefore not undone when the list exhausts. Every goto unlock; (145/148/153/160/163/168) and the continue at 139 leaves vcp pointing at the most-recently-visited VC. When the list exhausts without break at 171, the post-loop block at 175-178 runs on that stale vcp:

• smb_vc_ref(vcp) = smb_co_ref (smb_conn.c:270-276), which atomically does cp->co_usecount++ under the spinlock with no SMBO_GONE check — so the bump succeeds even on a VC being torn down. One ref leaked per miss.
• *vcpp = vcp writes the wrong VC pointer through the caller's output parameter, even though the function is about to return a non-zero error.

The caller smb_sm_lookup (smb_conn.c:182-226) does NOT release *vcpp on the error path (lines 196-198: if (error == 0 || ...) { unlock; return; }), so the leaked ref is permanent.

Cascade: the VC's co_usecount grows without bound. When the VC's last legitimate reference is later dropped via smb_co_rele → smb_co_gone (smb_conn.c:249-268), the drain loop while (cp->co_usecount > 0) tsleep (&cp->co_lock, 0, "smbgone", hz); (lines 263-265) never exits, because no code path ever decrements the leaked reference. The closing thread (typically nsmb_dev_close → smb_vc_rele, smb_dev.c:156) is then permanently stuck in state 'smbgone'.

2. Reachability & threat model (why a code-level proof is appropriate here)

• The vulnerable code is optional netsmb (sys/conf/files:1870-1878) and is not in X86_64_GENERIC (only smbus hardware-bus devices are, which are unrelated — sys/bus/smbus/).
• The loadable KLD sys/vfs/smbfs/smbfs.ko compiles all of netproto/smb/*.c into one module (see its Makefile). Verified on this guest: make in /usr/src/sys/vfs/smbfs produces a 168760-byte smbfs.ko whose symbol table contains smb_sm_lookupint, smb_sm_lookup, and smb_vc_ref (see env.txt). kldload smbfs.ko succeeds (LOAD_RC=0) and creates /dev/nsmb mode 0700 root:wheel — exactly the threat model in the finding (smb_dev.c:356).
• Driving the bug end-to-end in-kernel additionally requires a VC already in the vclist. A VC only appears there after a successful smb_sm_lookup(... SMBV_CREATE ...) → smb_vc_create → smb_vc_connect round-trip to a real SMB server (none reachable on this isolated guest). Without a VC in the list the SMBCO_FOREACH body never runs, vcp stays NULL, and the leak does not fire. This is an environmental limitation of the test guest, not a defect in the bug claim.
• Per the DF-0265 / DF-0617 precedent, the bug is therefore demonstrated by a code-level proof: a userspace harness replicating smb_sm_lookupint's exact control flow, plus (going beyond the precedent) disassembly of the actual shipped KLD confirming the compiler retained the stale-write.

3. Reproduction — userspace harness (deterministic)

leak.c replicates smb_sm_lookupint line-for-line (with the comparison fields modelled by trivial int/const char * stand-ins, and the unused shspec/ssp half elided). It builds a 3-VC vclist and issues N lookups with a non-matching username. Output (see leak_sample.txt, run.log, run.1000.log):

=== VULNERABLE smb_sm_lookupint (sys/netproto/smb/smb_conn.c:123-180) ===
  call #0: rc=1 (nonzero => lookup FAILED), but *vcpp=alice@a (NOT NULL!)
  after 10 failed lookups:
    usecount[alice@a] = 11  (baseline 1, delta +10)    <-- +10 leaked refs
    usecount[bob@b]   = 1  (baseline 1, delta +0)
    usecount[carol@c] = 1  (baseline 1, delta +0)
    TOTAL leaked refs across all VCs = 10  (expected 10)
    every miss returned *vcpp=alice@a (WRONG VC ...)

At N=1000 the leak is exactly +1000 (linear, unbounded). The leaked refs all land on one VC — the last one SMBCO_FOREACH visited before the list exhausted — matching the source analysis. Both effects the finding claims are reproduced: (a) one ref leaked per miss, and (b) the wrong VC returned through *vcpp even though error != 0.

4. Reproduction — compiled-KLD binary proof (the compiler did NOT mask it)

A subtle concern with stale-variable bugs is that an optimizing compiler might unify scp and vcp (the cast (struct smb_vc *)scp is a no-op because struct smb_vc's first member is struct smb_connobj obj;). If gcc had done that, the SLIST_FOREACH iterator update would clear vcp too and the bug would be latent at runtime. It did not. Disassembling the actual shipped smbfs.ko (objdump -d, full dumps in unpatched.dis / patched.dis) confirms the stale-vcp path is live in the compiled object:

Unpatched smb_sm_lookupint (built from the verbatim audited source):

    1e93: mov 0x48(%r14),%rax        # SLIST_NEXT (scp = scp->co_next)
    1e97: test %rax,%rax
    1e9a: je   1fa0                  # list exhausted (no match) -> 1fa0
    ...
    1fa0: mov  %r14,%rdi             # arg0 = r14 = STALE (last VC visited)
    1fa3: callq 8f0 <smb_co_ref>     # smb_vc_ref(stale)  <-- REF LEAKED
    1fa8: mov  %r14,0x0(%r13)        # *vcpp = stale      <-- WRONG VC WRITTEN
    1fac: add  $0x18,%rsp            # epilogue

The list-exhaustion branch (je 1fa0) lands directly on the mov %r14,%rdi / callq smb_co_ref block. The compiler kept vcp in %r14 across iterations and did not clear it on list exhaustion — exactly the source-level bug. Every list-exhausting miss takes a ref on the last VC and writes it through *vcpp.

Patched smb_sm_lookupint (built from fix.diff applied):

    1e95: mov 0x48(%r12),%r12        # SLIST_NEXT
    1e99: test %r12,%r12
    1e9d: je   1fa6                  # list exhausted -> 1fa6 (EPILOGUE)
    ...
    1f94: mov  %r12,%rdi             # success path only
    1f97: xor  %r14d,%r14d
    1f9a: callq 8f0 <smb_co_ref>     # smb_vc_ref  (only on success)
    1f9f: mov  -0x38(%rbp),%rax
    1fa3: mov  %r12,(%rax)           # *vcpp = vcp (only on success)
    1fa6: add  $0x18,%rsp            # epilogue (list-exhaustion lands here)

The list-exhaustion branch (je 1fa6) now jumps past the ref block straight to the epilogue. smb_co_ref and the *vcpp write are reachable only from the success path (1f94). The leak is closed at the binary level.

5. Impact

• Memory-exhaustion DoS (straight-line, 100% reliable): each failing SMBIOC_LOOKUP / SMBIOC_OPENSESSION ioctl leaks one ref onto a victim VC. vmstat -m / the netsmb slab grows monotonically; the VC can never be freed.
• Kernel-thread hang (race-y but practical): race a thread dropping the last legitimate ref on a VC against another thread's failing lookup that lands its leaked ref on the same VC; the closer blocks forever in smb_co_gone's drain loop (smb_conn.c:263-265), state 'smbgone'.
• Confused-deputy: *vcpp is set to a VC that does not match the request, so a caller that mistakenly trusts *vcpp on a non-zero error return could operate on the wrong session. (The in-tree caller smb_sm_lookup checks error first, so this is latent in-tree; third-party callers of smb_sm_lookupint would be at risk.)
• Privilege requirement: /dev/nsmb is mode 0700 root:wheel (smb_dev.c:356). Root (or a confused-deputy setuid helper such as a hypothetical setuid mount_smbfs) is required. No info leak, no code-exec primitive derives from this bug — it is a pure refcount-leak DoS.

Severity Medium (CVSS 3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H ≈ 6.2) is appropriate: reliable local DoS, but requires SMB-client KLD loaded and root-or-setuid-deputy access to /dev/nsmb.

6. Fix validation (Phase 8)

The fix is the one already proposed in the finding's ## Recommended fix, refined to a clean two-hunk git apply-able diff (fix.diff):

1. vcp = NULL; on the smb_vc_lock-fail continue path (lines 138-140) — closes the EINVAL-on-a-VC-entering-SMBO_GONE variant.
2. vcp = NULL; at the unlock: label (line 174) — closes the list-exhausting-miss path, the main variant.
3. if (error == 0 && vcp) guard on the post-loop ref block (line 175) — belt-and-suspenders: even if a future edit reintroduces a stale vcp, no ref is taken unless the lookup actually succeeded.

Validation performed (full logs in fix_build.log, fix_build_unpatched.log, unpatched.dis, patched.dis):

The bug is not in the running #0 kernel (netsmb not in GENERIC), so there is no in-kernel "before/after" runtime contrast on this guest — but the shipped KLD object code demonstrably contains the leak (unpatched) and demonstrably does not (patched), and the C-level harness confirms the logic at arbitrary scale. fix_status = fixed.

7. PoC changes

The PoC scaffold shipped only a README.md (no source). I added: - leak.c — userspace harness replicating smb_sm_lookupint (vulnerable + fixed variants) line-for-line, with a 3-VC driver demonstrating the leak. - build.sh / run.sh — exact build (plain cc -O2 -Wall -Wextra) and run. - fix.diff — standalone git apply-able two-hunk fix (refines the finding's proposal into a clean diff that compiles + loads). - Full untrimmed logs: build.log, run.log, run.1000.log, fix_build.log, fix_build_unpatched.log, unpatched.dis, patched.dis. - leak_sample.txt, env.txt, this VERDICT.md, manifest.json.

8. Notes / caveats / what to try next

• The in-kernel end-to-end trigger (refcount growth visible via vmstat -m or a sysctl net.smb.treedump) was not exercised because no SMB server is reachable from this guest and the bug only fires once a VC is in the vclist. To reproduce in-kernel: stand up an SMB server reachable from the guest, mount it once via mount_smbfs to populate the vclist, then issue ioctl(fd, SMBIOC_LOOKUP, ...) with a non-matching username in a loop and watch the victim VC's co_usecount climb via a net.smb.treedump-style sysctl or vmstat -m. The harness + KLD disassembly are sufficient proof in the absence of that server.
• The finding's recommended fix is correct; my fix.diff refines it (adds the vcp = NULL on the lock-fail continue path, which the finding's diff did not cover) and validates it at the compiled-code level. Supersedes the finding proposal (strictly more complete).
• The bug is a clean CWE-911 (Improper Update of Reference Count); the confused-deputy *vcpp-on-miss angle additionally rates a CWE-672 mention.