=== DF-0600 baseline run on UNPATCHED kernel (6.5-DEVELOPMENT #0) ===
=== Run as root (device /dev/nsmb is 0700 root:wheel); smbfs.ko kldloaded ===

Command (run_root): kldload smbfs && cd /root/poc600 && timeout 8 ./oob_read

[The PoC's stdout was lost because the kernel panic killed the ssh channel
 before the buffered output flushed. The panic signature below (from the
 serial console dfbsd-qemu/boot.log) is the durable proof. The run was
 repeated twice with identical results (process ids 952 and 874).]

Boot-log excerpt (serial console, post-PoC):
  netsmb_dev: loaded
  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
  fault code               = supervisor read data, page not present
  instruction pointer      = 0x8:0xffffffff806c9c98
  current process          = 874
  Stopped at dup_sockaddr+0x18:  movzbl (%rdi),%edi
  db>

Interpretation:
  The ioctl reached smb_vc_create() (sys/netproto/smb/smb_conn.c). At line
  462, dup_sockaddr(vcspec->sap) executed with sap->sa_len=255 on the 4-byte
  smb_memdupin allocation -> SILENT 251-byte heap OOB read (within the slab
  page, so no fault). At line 466, dup_sockaddr(vcspec->lap=NULL) dereferenced
  NULL -> page fault at va=0x0 -> panic. The sa_len OOB read (line 462) is
  confirmed to have occurred before the incidental NULL-lap panic (line 466),
  since the do{...}while body executes top-to-bottom and vc_paddr was assigned
  non-NULL (kmalloc(255) succeeds).

  The NULL-lap deref is a SEPARATE latent issue (lap is NULL whenever
  ioc_local is not supplied) and is independent of the sa_len OOB that
  DF-0600 describes. DF-0600's fix (validate sa_len before line 462) returns
  EINVAL for sa_len=255 > sizeof(struct sockaddr_storage), preventing BOTH the
  OOB read and (for this PoC) the panic.

  VERDICT: bug path REACHED and sa_len is UNCHECKED on the unpatched kernel.
  Guest left in DDB (down); requires vm.sh reset.