DragonFlyBSD Kernel Audit
DF-0599 / fix_run.log
← back to finding ↓ download raw
=== DF-0599 fix-validation run on PATCHED smbfs.ko ===
base kernel (UNCHANGED): DragonFly 6.5-DEVELOPMENT #0: Thu Jul  2 06:02:54 UTC 2026
NOTE: DF-0599 lives in the loadable module smbfs.ko (sys/vfs/smbfs/Makefile,
.PATH netproto/smb), NOT in the base kernel. So the fix was validated by
rebuilding ONLY smbfs.ko from patched source and replacing /boot/kernel/smbfs.ko.
  original /boot/kernel/smbfs.ko sha256: d854773e5b3642544c89d4adebe20efb5e54258aaffcfea61694006d1cd54895
  patched  /boot/kernel/smbfs.ko sha256: b522d33049b4e5c8d31810871b6cca67f11a1e311b1ae5cc060acb25f7ff06d2

trigger (run as root):
  $ kldload smbfs      # loads the PATCHED module
  $ ./panic

decisive run output:
[*] DF-0599: issuing SMBIOC_OPENSESSION with localcs="BOGUSCS-9" (size=488)
[!] ioctl returned rc=-1 errno=2 (m)        <-- ENOENT (2), returned cleanly
RUN_EXIT=0
<< guest stayed UP; ssh rc=0; NO panic in boot.log >>

3x repeat (determinism):
run 1: [!] ioctl returned rc=-1 errno=2 (m)
run 2: [!] ioctl returned rc=-1 errno=2 (m)
run 3: [!] ioctl returned rc=-1 errno=2 (m)
vm status after all runs: up
panic lines in boot.log (current boot): 0

CONCLUSION: With the fix, smb_vc_create's iconv_open(ENOENT) error path is
handled gracefully -- the NULL vc_iod guard in smb_vc_gone() skips
smb_vc_disconnect(), and ENOENT propagates back to userspace. No panic.