DF-0600 — PoC: dup_sockaddr sa_len OOB read

Privileged local heap OOB read. dup_sockaddr trusts sa->sa_len unconditionally; smb_memdupin allocates from user-supplied ioc_svlen. A user who supplies ioc_svlen=4 with a sockaddr whose first byte (sa_len) is 200 causes dup_sockaddr to bcopy 200 bytes out of a 4-byte kernel heap allocation.

Files

• oob_read.c — minimal reproducer (SMBIOC_OPENSESSION with mismatched ioc_svlen vs sa_len).
• (added by per-PoC verifier) build.sh, run.sh, build.log, run.log, VERDICT.md, manifest.json, fix.diff.

Build & run

cc -I/usr/src/sys -I/usr/src/sys/netproto/smb -o oob_read oob_read.c
sudo ./oob_read

Expected first outcome

dup_sockaddr will bcopy 200 bytes from the 4-byte buf → heap OOB read. Either panics (if buf is at page boundary) or silently copies 196 adjacent bytes into vcp->vc_paddr. The silent-copy case is observable only via the CONNADDREQ comparison oracle in subsequent SMBIOC_LOOKUP calls.

Notes for the per-PoC verifier

• The OOB read itself can panic the kernel if the source buffer is at the end of a slab page and the read crosses an unmapped page; otherwise it silently copies adjacent heap into vc_paddr.
• The indirect-comparison oracle (via CONNADDREQ in smb_sm_lookupint) provides a 1-bit (match/no-match) signal per attempt — a byte-by-byte brute-force of the leaked contents is possible with effort but requires heap-layout determinism.
• Verify the fix with git apply findings/poc/DF-0600/fix.diff (the sa_len validation before dup_sockaddr calls in smb_vc_create); after the fix the ioctl should return EINVAL cleanly without OOB read.

DF-0600 — Verdict

Verdict: REPRODUCED (defense-in-depth / hardening gap; root-only reachability)

The bug is real: dup_sockaddr() (sys/kern/uipc_socket2.c:808-816) trusts sa->sa_len unconditionally (kmalloc(sa->sa_len); bcopy(sa, sa2, sa->sa_len)), and smb_memdupin() (sys/netproto/smb/smb_subr.c:137-148) allocates a buffer of size ioc_svlen/ioc_lolen (the user-supplied length) with no cross-check against the sa_len field inside the copied-in sockaddr. A mismatch (sa_len > ioc_svlen) drives a heap OOB read of up to ~251 bytes (sa_len is u_char, max 255; allocation 4 bytes → 251 bytes OOB). The finding is correct.

However, the impact is capped at a root-only hardening gap — not an unprivileged→root escalation — for a definitive reason:

Threat model / reachability — root-only (valid Phase 6 hard blocker)

The vulnerable code path (SMBIOC_OPENSESSION ioctl → smb_usr_opensession → smb_sm_lookup → smb_vc_create → dup_sockaddr) is reachable only by root:

1. Module not loaded by default. netsmb/smbfs is optional netsmb in sys/conf/files and is NOT in X86_64_GENERIC (sys/config/X86_64_GENERIC lists only smbus/smbacpi — the SMBus hardware bus, unrelated). The guest boots with no /dev/nsmb*. Loading requires kldload smbfs → root only.
2. Device is 0700 root:root. make_autoclone_dev(... 0700, NSMB_NAME) at sys/netproto/smb/smb_dev.c:355-356. Opening /dev/nsmb requires root.
3. No setuid helper. mount_smbfs is not installed on the guest; no setuid-root SMB helper exists (find / -perm -4000 -name '*smb*' → empty).

An unprivileged user cannot load the module, open the device, or issue the ioctl. Root→kernel is game-over by definition; there is no privilege boundary to cross. This is one of the explicitly-listed valid Phase 6 hard blockers. Per the bright-line rule, this finding is not a uid0 escalation — it is a root→kernel hardening gap (the finding correctly rates it Low).

Mechanism (confirmed, every hop cited)

1. nsmb_dev_ioctl SMBIOC_OPENSESSION (smb_dev.c:187) → smb_usr_opensession (smb_usr.c:164-178).
2. smb_usr_vc2spec (smb_usr.c:60): spec->sap = smb_memdupin(dp->ioc_server, dp->ioc_svlen) — allocates exactly ioc_svlen bytes (smb_subr.c:137-148), no check that sap->sa_len <= ioc_svlen.
3. smb_usr_opensession sets SMBV_CREATE (smb_usr.c:175) → smb_sm_lookup (smb_conn.c:183): empty VC list → smb_sm_lookupint returns ENOENT → smb_vc_create (smb_conn.c:202).
4. smb_vc_create (smb_conn.c:462): vcp->vc_paddr = dup_sockaddr(vcspec->sap).
5. dup_sockaddr (uipc_socket2.c:809-815): kmalloc(sa->sa_len); bcopy(sa, sa2, sa->sa_len) — if sa_len > ioc_svlen, the bcopy reads (sa_len - ioc_svlen) bytes past the smb_memdupin allocation → heap OOB read.
6. sa_len is u_char (max 255); with ioc_svlen=4 the OOB is 251 bytes, all within the same slab page → silent read (no panic from the OOB itself). The leaked bytes land in vcp->vc_paddr; reachable indirectly via the CONNADDREQ 1-bit comparison oracle (smb_conn.h:178, smb_sm_lookupint:143).

Reproduction on the unpatched kernel (6.5-DEVELOPMENT #0)

The PoC (oob_read.c) opens /dev/nsmb, issues SMBIOC_OPENSESSION with ioc_svlen=4 and sa_len=255 (+SMBVOPT_CREATE), and ioc_local=NULL.

Result: kernel PANIC. The first dup_sockaddr(vcspec->sap) (smb_conn.c:462) executes the 251-byte OOB read silently (in-slab-page), then the second dup_sockaddr(vcspec->lap=NULL) (smb_conn.c:466) dereferences NULL → page fault. Serial-console panic signature (boot.log):

Fatal user address access from kernel mode from oob_read at ffffffff806c9c98
Fatal trap 12: page fault while in kernel mode
fault virtual address    = 0x0
Stopped at dup_sockaddr+0x18:  movzbl (%rdi),%edi

The OOB read at line 462 provably executed before the incidental NULL-lap deref at line 466 (the do{...}while body is sequential; vc_paddr was assigned non-NULL). Deterministic across 2 runs (PIDs 952, 874).

Escalation assessment — blocked (valid hard blocker)

Primitive is an OOB read (not a write): bcopy reads past the source allocation into a fresh destination. No corruption of kernel objects occurs (the destination is freshly kmalloc'd). The leaked bytes are only reachable via the indirect CONNADDREQ 1-bit oracle. Combined with the root-only reachability, there is no unprivileged escalation path: - The primitive is read-only (no write/corruption) → no slab grooming, no pointer overwrite, no refcount attack. - Root→kernel is game-over; no privilege boundary to cross. - No setuid helper / world-readable device / auto-load path exists.

This is a valid hard blocker (read-only primitive + root-only reachability).

Fix (VALIDATED)

The validated fix lives in smb_usr.c (smb_usr_vc2spec), validating sa_len against the actual allocation before the sockaddr reaches dup_sockaddr. This supersedes the finding's smb_conn.c proposal (which triggered a pre-existing NULL-deref in smb_vc_disconnect when the EINVAL cleanup freed a partially- initialized VC whose vc_iod was NULL — see PoC-changes note below).

Before (unpatched, #0): PoC → PANIC at dup_sockaddr+0x18 (after the 251-byte OOB read). Guest down. After (fixed smbfs.ko): PoC → ioctl rc=-1 errno=22 (EINVAL), clean exit, guest up. Deterministic over 2 runs.

The fix checks sa_len < 2 || sa_len > ioc_svlen (and likewise for lap) right after each smb_memdupin call, returning EINVAL before smb_sm_lookup / smb_vc_create is ever entered — so no VC is allocated and no cleanup path runs.

PoC changes

• Wrote oob_read.c (the finding shipped only a README): opens /dev/nsmb, issues SMBIOC_OPENSESSION with ioc_svlen=4, sa_len=255, SMBVOPT_CREATE. Added setvbuf(stdout, NULL, _IONBF, 0) so output survives a kernel crash.
• Wrote valid_sa.c (diagnostic): confirmed the smb_iod_request crash is a pre-existing module issue (fires on any VC creation with a valid sa_len), independent of DF-0600. This is why the finding's smb_conn.c fix location doesn't validate cleanly: the EINVAL cleanup path (smb_vc_put → smb_vc_gone → smb_vc_disconnect:681 → smb_iod_request(vc_iod=NULL)) NULL-derefs because vc_iod was never created. The smb_usr.c fix avoids this entirely by rejecting the bad sa_len before VC allocation.
• Authored fix.diff against sys/netproto/smb/smb_usr.c (supersedes the finding's smb_conn.c proposal).

Impact ceiling

Low. Root-only OOB heap read of ≤251 bytes, observable only via a 1-bit indirect comparison oracle. No write primitive, no unprivileged reachability. The finding's CVSS (3.0, Low) and CWE-125 classification are accurate.