DF-0599 — PoC: smb_vc_create NULL-iod panic via invalid charset

Privileged local deterministic kernel panic. iconv_open returns ENOENT for any charset pair that has no registered converter; smb_vc_create's error path invokes smb_vc_gone → smb_vc_disconnect → smb_iod_request(vcp->vc_iod=NULL, ...), which executes SMB_IOD_EVLOCK(NULL) = smb_sl_lock(&NULL->iod_evlock) and page-faults.

Files

• panic.c — minimal reproducer (SMBIOC_OPENSESSION with an unregistered ioc_localcs).
• build.sh / run.sh — exact build/run commands.
• fix.diff — git-apply-able fix (NULL-guard in smb_vc_gone + clear vc_iod in smb_iod_create failure path).
• VERDICT.md — full root-cause confirmation + before/after fix validation.
• manifest.json — machine-readable artifact catalog.
• Logs: build.log, run.log (baseline panic), panic.txt, fix_build.log, fix_run.log (patched no-panic), env.txt.

Preconditions

• DragonFly master DEV kernel 6.5-DEVELOPMENT #0 (unpatched baseline).
• The netsmb stack is a loadable module: kldload smbfs (pulls in libmchain.ko + libiconv.ko) creates /dev/nsmb.
• No iconv converter modules loaded (the default) ⇒ any charset name yields ENOENT from iconv_open. We use "BOGUSCS-9" (≤15 chars; ioc_localcs is 16 bytes).
• Must run as root — /dev/nsmb is mode 0700 root:wheel (smb_dev.c:356). On this guest mount_smbfs is 0555 root:wheel (not setuid), so the direct ioctl trigger is the repro path. The realistic unprivileged vector is a privileged confused-deputy mounting with a negotiated charset whose module is absent.

Build & run

./build.sh                 # cc -Wall -O2 -o panic panic.c
sudo ./run.sh              # kldload smbfs ; ./panic   (run as root)

Expected outcome

Unpatched #0 + original smbfs.ko — immediate kernel panic (serial console captured in panic.txt / run.log):

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x58
Stopped at      smb_iod_request+0x58:   lock xaddl      %edx,0x58(%rbx)
db>

(%rbx = 0 ⇒ vc_iod == NULL; 0x58 = offset of iod_evlock in struct smbiod.)

Patched smbfs.ko (rebuilt from fix.diff) — the ioctl returns cleanly:

[*] DF-0599: issuing SMBIOC_OPENSESSION with localcs="BOGUSCS-9" (size=488)
[!] ioctl returned rc=-1 errno=2 (m)        # ENOENT, no panic, guest stays up

Reproducing the fix validation

Because DF-0599 lives in the loadable smbfs.ko module (not the base kernel), the fix is validated by rebuilding only that module:

# on the guest, with fix.diff applied to /usr/src:
cd /usr/src/sys/vfs/smbfs && make
cp /usr/obj/usr/src/sys/vfs/smbfs/smbfs.ko /boot/kernel/smbfs.ko && sync
kldload smbfs
./panic          # now returns ENOENT, no panic

See VERDICT.md for the full mechanism trace and before/after evidence.

DF-0599 — VERDICT

Verdict: REPRODUCED (panic), then FIX VALIDATED

The bug is real and deterministically triggerable on the audited DragonFly master DEV kernel (6.5-DEVELOPMENT #0). A single SMBIOC_OPENSESSION ioctl with an unregistered ioc_localcs charset name panics the kernel via a NULL vc_iod dereference in smb_iod_request. The authored fix.diff closes it: on the patched smbfs.ko the ioctl returns ENOENT cleanly with no panic.

Mechanism (confirmed, every hop cited)

1. Trigger (root) — open("/dev/nsmb") then ioctl(fd, SMBIOC_OPENSESSION, &ssn) with ioc_localcs="BOGUSCS-9". /dev/nsmb is mode 0700 root:wheel (sys/netproto/smb/smb_dev.c:356), so the direct trigger needs root (or a privileged confused-deputy such as a hypothetical setuid mount_smbfs — on this guest mount_smbfs is 0555 root:wheel, not setuid). The netsmb stack is a loadable module: kldload smbfs brings in smbfs.ko + libmchain.ko + libiconv.ko and creates /dev/nsmb.

2. Dispatch — SMBIOC_OPENSESSION (sys/netproto/smb/smb_dev.c:187-191) → smb_usr_opensession (sys/netproto/smb/smb_usr.c:163-180) → smb_usr_vc2spec (only validates ioc_user[0], ioc_server!=NULL, ioc_localcs[0]!=0; does not validate the charset against a real kiconv cspair — smb_usr.c:65-72) → smb_sm_lookup with SMBV_CREATE.

3. Create + charset failure — smb_sm_lookup (smb_conn.c:202) calls smb_vc_create. At smb_conn.c:486 it does iconv_open("tolower", vcspec->localcs, &vcp->vc_tolower). With zero iconv converter modules loaded (only the libiconv.ko framework; no cspairs registered), iconv_open (sys/libiconv/iconv.c:233-267) finds no matching cspair and returns ENOENT (iconv.c:266). The do/while breaks.

4. Error cleanup → NULL iod deref — smb_vc_create error path (smb_conn.c:512-513) calls smb_vc_put(vcp) → smb_co_put (smb_conn.c:337-364) drops usecount to 0 → smb_co_gone (smb_conn.c:249-268) → dispatches cp->co_gone = smb_vc_gone (smb_conn.c:550-556) → smb_vc_disconnect(vcp) (smb_conn.c:678-684) → smb_iod_request(vcp->vc_iod, ...). But vc_iod is still NULL: smb_zmalloc zeroed it (smb_conn.c:437) and smb_iod_create (smb_conn.c:504) never ran.

5. PANIC — smb_iod_request(NULL, ...) executes SMB_IOD_EVLOCK(iod) = smb_sl_lock(&iod->iod_evlock) (sys/netproto/smb/smb_iod.c:403, macro at smb_iod.c:58), which dereferences NULL + offsetof(struct smbiod, iod_evlock) (= 0x58 on this build) and takes a page fault.

Evidence — baseline (unpatched #0 + original smbfs.ko)

Serial console (dfbsd-qemu/boot.log):

Fatal user address access from kernel mode from panic at ffffffff82609ab8
Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic id = 0
fault virtual address   = 0x58
fault code              = supervisor write data, page not present
instruction pointer     = 0x8:0xffffffff82609ab8
kernel: type 12 trap, code=2
Stopped at      smb_iod_request+0x58:   lock xaddl      %edx,0x58(%rbx)
db>

IP 0xffffffff82609ab8 = smbfs.ko base 0xffffffff82600000 + smb_iod_request@0x9a60 + 0x58. %rbx=0 ⇒ vc_iod==NULL. The fault address 0x58 is the offset of iod_evlock inside struct smbiod (sys/netproto/smb/smb_conn.h:448), exactly as predicted. Deterministic — straight-line code, no race.

(The finding predicted fault addr ≈ 0x40; the actual offset is 0x58 because iod_evlock sits after several pointer/int fields. Same bug, same function, same root cause.)

PoC changes (what I authored and why)

The finding shipped no trigger source — only a README. I authored panic.c from the cited path. One precondition fix during iteration:

• First run panicked at dup_sockaddr+0x18 (fault addr 0x0), not at smb_iod_request. Root cause: my first PoC left ioc_local=NULL, and smb_vc_create calls dup_sockaddr(vcspec->lap) unconditionally at smb_conn.c:466 — before reaching the iconv_open at line 486 — so it NULL-deref'd lap first. Fix: supply a valid ioc_local sockaddr so the flow reaches the charset error path. (This is an incidental additional latent NULL-deref in the same function — smb_usr_vc2spec skips setting lap when ioc_local==NULL but smb_vc_create assumes it is set — same class, same trigger surface; noted but not the subject of DF-0599.)
• Used a 9-char bogus charset ("BOGUSCS-9") because ioc_localcs is only 16 bytes; the README's "THIS_CHARSET_DOES_NOT_EXIST_9" would not fit.
• Set ioc_servercs[0]='\0' so only the two tolower/toupper iconv_open calls run (the trigger), skipping the toserver/tolocal block.
• Defined the smbioc_ossn struct field-for-field from sys/netproto/smb/smb_dev.h:65-83 so the ioctl copyin size matches the kernel exactly (computed via _IOW('n',100,struct smbioc_ossn)).

Exploit chain

Not a memory-corruption primitive — it is a NULL-deref page fault at a fixed small offset (0x58). map_at_zero is off by default on DragonFly, so the fault address is unmappable and yields only a local kernel panic / DoS (whole-host). No info leak, no code execution, no privilege escalation. The finding's severity (Medium, CVSS 6.2, C:N/I:N/A:H) is accurate.

Fix (verified)

fix.diff (git-apply-able, plain unified diff so DragonFly patch -p1 also accepts it) makes two minimal changes:

1. smb_vc_gone (sys/netproto/smb/smb_conn.c) — guard the disconnect: if (vcp->vc_iod != NULL) smb_vc_disconnect(vcp);. This is the real fix for the NULL-deref: when smb_vc_create failed before smb_iod_create succeeded, there is no iod to disconnect from.

2. smb_iod_create (sys/netproto/smb/smb_iod.c) — on kthread_create_compat failure, set vcp->vc_iod = NULL before kfree(iod). This closes the related UAF variant the finding describes (smb_iod.c:699 sets vc_iod=iod, then :708 frees iod without clearing vc_iod, so the same gone-hook would UAF the freed iod).

This matches the finding's ## Recommended fix proposal (gone-hook guard + iod_create NULL-clear). It omits the optional KKASSERT in smb_vc_disconnect (the guard makes it unreachable with NULL) and omits the optional early localcs/servercs validation in smb_usr.c (defense in depth, not required to close the panic).

Why I rebuilt the module, not nativekernel

smbfs is optional netsmb in sys/conf/files and ships as a loadable module (sys/vfs/smbfs/Makefile, .PATH netproto/smb) — it is not compiled into the X86_64_GENERIC kernel (confirmed: no smb symbols / /dev/nsmb until kldload smbfs). Therefore make nativekernel would not have picked up the fix. The correct validation unit was rebuilding only smbfs.ko from patched source (cd /usr/src/sys/vfs/smbfs && make), replacing /boot/kernel/smbfs.ko, and kldload-ing it. The base kernel stays #0 (unchanged) — the fix lives entirely in the module.

Before / after