=== DF-0788 live mount trigger panic signature (from dfbsd-qemu/boot.log) ===

The crafted NTFS image (ntfs_0788.img) mounts SUCCESSFULLY on the unpatched
#0 kernel, proving the mount-time OOB memcpy in ntfs_attrtontvattr completes
(reads ~152 bytes past the 4096-byte MFT record buffer into adjacent M_TEMP
slab heap without faulting — a silent heap info leak into vap->va_datap).

The subsequent `ls /mnt/ntfs` (getdirentries -> ntfs_readdir -> ntfs_ntreaddir)
hits the SIBLING DF-0786 lockmgr panic (a different bug in the readdir path):

vn0: MBR magic not found; assume a COMPATIBILITY_SLICE (s0)
panic: lockmgr: locking against myself
cpuid = 0
Trace beginning at frame 0xfffff80117e49518
lockmgr_exclusive() at lockmgr_exclusive+0x3e0 0xffffffff80647f30 
lockmgr_exclusive() at lockmgr_exclusive+0x3e0 0xffffffff80647f30 
ntfs_ntreaddir() at ntfs_ntreaddir+0x58 0xffffffff826045f8 
ntfs_readdir() at ntfs_readdir+0xee 0xffffffff8260185e 
vop_readdir() at vop_readdir+0xb3 0xffffffff8070b1c3 
kern_getdirentries() at kern_getdirentries+0xdc 0xffffffff80706a3c 
Debugger("panic")

CPU0 stopping CPUs: 0x0000003e
 stopped
Stopped at      Debugger+0x7c:  movb    $0,0xbdaf09(%rip)
db> 

NOTE: The DF-0788 OOB read (the info leak) fires DURING MOUNT, before this
readdir panic. The mount returning rc=0 IS the proof the OOB memcpy completed.
The panic is the sibling DF-0786 bug, NOT DF-0788. The DF-0788 primitive
itself is a silent heap OOB read (no panic from the leak itself on this slab
layout). The deterministic harness (harness.c) proves the OOB read with a
guard page.