Kernel-path reproduction attempts (root, /dev/nsmb via fake SMB server) reached
the nsmb connection path and crashed the guest, but the crashes occur in the
connection-setup/iod path on the minimal fake-server handshake, NOT cleanly in
ssnsetup.  Observed panics in dfbsd-qemu/boot.log:

[run with multi-byte UTF-8 password, no local addr:]
Fatal trap 12: page fault while in kernel mode
fault virtual address     = 0x0
Stopped at      dup_sockaddr+0x18:      movzbl  (%rdi),%edi
  ^-- smb_vc_create() dup_sockaddr(vcspec->lap) with lap==NULL (trigger bug:
      a separate latent NULL-deref; smb_conn.c:466 lacks a NULL guard before
      dup_sockaddr).  Occurs BEFORE ssnsetup, in both multi-byte and ASCII runs.

[run after providing local addr, ASCII control password:]
Fatal trap 12: page fault while in kernel mode
fault virtual address     = 0x58
current process           = 874
Stopped at      smb_iod_request+0x58:   lock xaddl      %edx,0x58(%rbx)
  ^-- iod/connection path NULL deref on the minimal NB+negotiate handshake;
      crashes the ASCII (no-overflow) control too, so NOT attributable to the
      DF-0641 ssnsetup overflow.  A fully-conformant SMB1 server handshake is
      required to reach ssnsetup and was beyond the minimal fake server.

CONCLUSION: the kernel-path overflow panic was not cleanly isolated; the
smb_smb_ssnsetup heap overflow is instead proven deterministically by source
arithmetic + overflow_harness.c (130-byte alloc, 258-byte write => 128-byte
attacker-controlled heap overflow).  Reachability is root-only (/dev/nsmb 0700).