DF-0715 — smb_memdupin signed-length validation accepts zero

Summary

smb_memdupin (sys/netproto/smb/smb_subr.c:137) validates its int len parameter only with a signed > 8*1024 check. When len == 0, DragonFly's kmalloc(0) returns the sentinel ZERO_LENGTH_PTR = ((void*)-8) (not NULL), which the sole caller smb_usr_vc2spec (smb_usr.c:74-76) fails to catch with its == NULL check. The sentinel pointer flows to dup_sockaddr (smb_conn.c:462) which dereferences sa->sa_len at address 0xFFFFFFFFFFFFFFF8 — a non-canonical x86-64 address — causing a kernel panic (fatal trap 12 / GPF). When len < 0, the signed check passes and kmalloc receives a wrapped-to-huge size_t, panicking in the slab allocator.

Impact

Low — root→kernel DoS. The only path is /dev/nsmb (0700 root:wheel). No unprivileged escalation; no memory-corruption primitive (the GPF fires before any write).

Build

cc -o smb_memdupin_zero smb_memdupin_zero.c

Run (must be root; needs smbfs.ko loaded)

kldload smbfs        # admin precondition: load the SMB client module
./smb_memdupin_zero

Expected (bug present — unpatched)

Kernel panic:

Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xfffffffffffffff8
Stopped at dup_sockaddr+0x18: movzbl (%rdi),%edi

Guest goes down (DDB prompt on serial console).

Expected (bug fixed — patched)

SMBIOC_OPENSESSION: Cannot allocate memory
ioctl returned -1 (errno=12)

Guest stays up; no panic.

Files

• smb_memdupin_zero.c — trigger PoC
• build.sh / run.sh — build/run scripts
• fix.diff — git-apply-able fix (reject len <= 0 in smb_memdupin + smb_memdup)
• VERDICT.md — full analysis
• panic.txt — panic signature from serial console
• run.log / fix_run.log — unpatched / patched run output
• fix_build.log — patched kernel+module build log
• env.txt — guest environment

DF-0715 — smb_memdupin signed-length validation accepts zero

Verdict

REPRODUCED — root→kernel panic (DoS). The bug is real and confirmed by a clean Fatal trap 12 at dup_sockaddr+0x18 reading address 0xfffffffffffffff8 (= ZERO_LENGTH_PTR). The fix (if (len <= 0 || len > 8*1024) return NULL) closes it: the patched kernel+module returns ENOMEM cleanly, no panic.

Severity / impact

Low — root→kernel DoS. The only path to smb_memdupin is via /dev/nsmb (the nsmb clone device), which is created 0700 root:wheel (smb_dev.c:355-356). An unprivileged user cannot open the device (vfs.usermount=0, no devfs rules loosening nsmb). An admin who has loaded smbfs.ko (normal SMB-client setup) presents the device to root, and root can then panic the kernel. No memory-corruption primitive is derived — the sentinel pointer (void*)-8 is dereferenced as a struct sockaddr *, causing a non-canonical-address GPF before any attacker-controlled write lands. This is a hardening gap, not an escalation vector.

Mechanism (trigger → primitive → effect)

Trigger

Open /dev/nsmb (root only) and issue SMBIOC_OPENSESSION with an smbioc_ossn struct where ioc_svlen == 0 (and ioc_server != NULL, ioc_user[0] != 0, ioc_localcs[0] != 0, ioc_opt = SMBVOPT_CREATE).

Data flow (every hop cited)

1. nsmb_dev_ioctl (smb_dev.c:171) dispatches SMBIOC_OPENSESSION → smb_usr_opensession (smb_usr.c:164).
2. smb_usr_opensession → smb_usr_vc2spec (smb_usr.c:171 → smb_usr.c:60).
3. smb_usr_vc2spec calls smb_memdupin(dp->ioc_server, dp->ioc_svlen) with ioc_svlen = 0 (smb_usr.c:74).
4. THE BUG — smb_memdupin (smb_subr.c:137-148): c if (len > 8 * 1024) // 0 > 8192 == false → passes return NULL; p = kmalloc(len, M_SMBSTR, M_WAITOK); // kmalloc(0) → ZERO_LENGTH_PTR DragonFly kmalloc(0) returns ZERO_LENGTH_PTR = ((void*)-8) (kern_slaballoc.c:193,889-890), not NULL. copyin(umem, p, 0) returns 0 (zero-length copy), so smb_memdupin returns (void*)-8.
5. Back in smb_usr_vc2spec: spec->sap = (void*)-8; if (spec->sap == NULL) return ENOMEM (smb_usr.c:75-76) — misses the sentinel (it is not NULL).
6. smb_usr_opensession → smb_sm_lookup (smb_usr.c:176) → smb_sm_lookupint (empty VC list → ENOENT) → since SMBV_CREATE is set, smb_vc_create (smb_conn.c:202,417).
7. THE PANIC — smb_vc_create calls dup_sockaddr(vcspec->sap) (smb_conn.c:462). dup_sockaddr (uipc_socket2.c:809) does: c sa2 = kmalloc(sa->sa_len, M_SONAME, M_INTWAIT); reading ((struct sockaddr *)-8)->sa_len at address 0xFFFFFFFFFFFFFFF8 — a non-canonical x86-64 address → GPF → Fatal trap 12.

Why the privilege check doesn't help

smb_suser(cred) (smb_conn.c:428) runs inside smb_vc_create, after smb_memdupin has already returned the sentinel. The check only gates uid/gid selection (smb_conn.c:431-434); it does not block the dup_sockaddr call at line 462. The real privilege boundary is the /dev/nsmb device open permission (0700 root:wheel).

The len < 0 variant

With ioc_svlen < 0, the signed check len > 8*1024 is false (negative is never > 8192), and kmalloc((size_t)negative, ...) wraps to a huge value, panicking in the slab allocator. The fix (len <= 0) closes both variants with one check.

Exploit chain

Not applicable — this is a pure DoS / hardening gap, not a memory-corruption primitive. The ZERO_LENGTH_PTR sentinel is dereferenced as a pointer, causing a GPF before any attacker-controlled data reaches a write target. No heap grooming, no victim object, no escalation chain is possible. The finding is correctly classified as Low severity (root→kernel DoS).

PoC changes

Authored from scratch (no prior PoC existed in findings/poc/DF-0715/): - smb_memdupin_zero.c — opens /dev/nsmb, fills smbioc_ossn with ioc_svlen=0 + SMBVOPT_CREATE, issues SMBIOC_OPENSESSION. Built with the guest's installed <netsmb/smb_dev.h>. - build.sh / run.sh — exact build/run commands. - fix.diff — git-apply-able unified diff: if (len <= 0 || len > 8*1024) return NULL in both smb_memdupin and smb_memdup (smb_subr.c:140,157).

Fix validation (Phase 8)

• Baseline (unpatched #0 kernel + unpatched smbfs.ko): PoC → Fatal trap 12: page fault while in kernel mode, fault virtual address = 0xfffffffffffffff8, Stopped at dup_sockaddr+0x18: movzbl (%rdi),%edi. Guest down. Reproduced twice from fresh with-src resets.
• Patched (#1 kernel + rebuilt smbfs.ko): applied fix.diff to /usr/src, rebuilt smbfs.ko module (make in sys/vfs/smbfs/), installed to /boot/kernel/smbfs.ko, kldload smbfs. PoC → SMBIOC_OPENSESSION: Cannot allocate memory (errno=12 = ENOMEM), exit 0, guest stays up. Reproduced twice (deterministic).
• fix_status: fixed — clean before/after contrast.

Recommended fix

fix.diff changes smb_memdupin and smb_memdup (both in sys/netproto/smb/smb_subr.c) from if (len > 8 * 1024) return NULL to if (len <= 0 || len > 8 * 1024) return NULL. This rejects zero (which causes kmalloc(0) → ZERO_LENGTH_PTR sentinel confusion) and negative (which wraps to a huge size_t in kmalloc) with a single signed check. Matches the finding proposal (if(len<=0||len>8*1024) return NULL).