================================================================================
DF-0907 run.log — decisive run evidence (consolidated from guest sessions)
================================================================================
Guest: DragonFly 6.5-DEVELOPMENT #0 (with-src baseline, INVARIANTS ON, GENERIC)
Module: /boot/kernel/smbfs.ko (sha256 d854773e... — shipping, UNPATCHED)

--------------------------------------------------------------------------------
[1] Arithmetic harness (deterministic proof of the pe-pc-2 underflow)
--------------------------------------------------------------------------------
$ ./harness
line 170: pe-pc-2 = (buf+80)-(buf+2)-2 = 76  (bound)
           -> size_t bound = 76
           after index: pc = buf+78 (NUL at buf+78)
line 171: pc < pe-1  ->  TRUE
line 172: wrote '@' at buf+78, pc now buf+79
line 173: pe-pc-2 = (buf+80)-(buf+79)-2 = -1  (ptrdiff_t)
           coerced to size_t (strncpy 3rd arg) = 18446744073709551615
           SIZE_MAX = 18446744073709551615
*** CONFIRMED: bound is (size_t)-1 == SIZE_MAX ***
*** strncpy would write vc_srvname + ~SIZE_MAX zero-padding ***
*** => heap overflow past f_mntfromname into struct statfs/mount ***
EXIT=0

--------------------------------------------------------------------------------
[2] Kernel trigger (80-char username) — guest DIES (separate iod-setup crash
    masks the overflow; the overflow code path IS confirmed present by
    disassembly of this exact module — see VERDICT.md)
--------------------------------------------------------------------------------
$ ./diag_lookup 80
[1] opened /dev/nsmb fd=3, username len=80
[2] calling SMBIOC_LOOKUP...
(<ssh hangs; guest panics during SMBIOC_LOOKUP>)

boot.log panic:
Fatal user address access from kernel mode from diag_lookup at ffffffff82609ab8
Fatal trap 12: page fault while in kernel mode
fault virtual address    = 0x58
instruction pointer      = 0x8:0xffffffff82609ab8
Stopped at smb_iod_request+0x58: lock xaddl %edx,0x58(%rbx)
(current process = diag_lookup; rbx=0 => smb_iod_request called with iod=NULL)

--------------------------------------------------------------------------------
[3] Control (9-char username, NO overflow possible) — IDENTICAL crash
    => proves the smb_iod_request panic is the separate iod-setup bug,
       NOT the DF-0907 overflow (which would zero mnt_data and cause a
       DIFFERENT, earlier EINVAL return from smbfs_root, not this crash)
--------------------------------------------------------------------------------
$ ./diag_lookup 9
[1] opened /dev/nsmb fd=3, username len=9
[2] calling SMBIOC_LOOKUP...
(<ssh hangs; identical panic>)
Stopped at smb_iod_request+0x58: lock xaddl %edx,0x58(%rbx)

--------------------------------------------------------------------------------
[4] Disassembly of shipping /boot/kernel/smbfs.ko smbfs_mount — the vulnerable
    SIZE_MAX-bound strncpy IS present in the live kernel module
--------------------------------------------------------------------------------
smbfs_mount relocations (objdump -dr /boot/kernel/smbfs.ko):
        abf1: R_X86_64_PLT32  strncpy-0x4     <- 1st strncpy (bound pe-pc-2 = 76)
        abfb: R_X86_64_PLT32  index-0x4
        ad7d: R_X86_64_PLT32  strncpy-0x4     <- 2nd strncpy (bound pe-pc-2 = -1 = SIZE_MAX) ***
        ad87: R_X86_64_PLT32  index-0x4
        adaf: R_X86_64_PLT32  strncpy-0x4     <- 3rd strncpy (ss_name)

Key arithmetic in the live module:
    abe8: sub $0x2,%rdx    # 1st bound = pe-pc-2 = 76
    ad78: sub $0x2,%rdx    # 2nd bound = pe-pc_new-2 -> 0xFFFFFFFFFFFFFFFF (SIZE_MAX)

--------------------------------------------------------------------------------
[5] After fix.diff (ksnprintf replacement): the vulnerable path is GONE
--------------------------------------------------------------------------------
smbfs_mount relocations in the FIXED module (objdump -dr):
        a511: R_X86_64_PLT32  ksnprintf-0x4    <- single bounded call
        (NO strncpy, NO index, NO sub $0x2, NO lea 0x1b2 in smbfs_mount)

Fixed module build: END_RC=0, no warnings (see fix_build.log).
Fixed module loads; behavior on the trigger is identical to the original
(both panic at smb_iod_request+0x58 — the separate iod bug) — confirming the
fix neither regresses nor affects the unrelated iod path.