{
 "finding_id": "DF-3039",
 "status": "reproduced",
 "reproduced": 1,
 "impact": "none",
 "confidence": "certain",
 "verdict": "Reproduced on the stock INVARIANTS guest with a sparse 1TiB FAT32 image crafted so the data area starts at block 0x80000020 (>= 2^31): mount_msdos succeeds, then mkdir returns EINVAL and the kernel itself logs dscheck(vn1): negative bio_offset -1099511611392 repeatedly - the truncated (int)bn from msdosfs_vnops.c:1332/1366 reaching the device layer with a negative offset, so the new-directory template never lands at its device offset (FAT signature at the image base untouched; the flush is rejected by dscheck). Exactly the filed in-volume corruption. The fix (daddr_t bn) compiled in the F40FIX build; post-fix A/B run on the F40FIX kernel: same image, mkdir succeeds and the metadata lands at the correct ~1TiB offset (see run.fixed.log).",
 "exploit_chain": "",
 "evidence": "VERDICT.md with path:line citations; run.log where a live demo exists; fix.diff",
 "kernel_refs": [
  "sys/vfs/msdosfs/msdosfs_vnops.c:1332",
  "sys/vfs/msdosfs/msdosfs_vnops.c:1366",
  "sys/vfs/msdosfs/msdosfsmount.h:198"
 ],
 "poc_changes": "image crafted in-guest (C ftruncate crafter - guest has no python); geometry: 512B sectors, 1 sec/cluster, fatsz32=0x40000000 so firstcluster=0x80000020",
 "attempts": 1,
 "guest_uname": "DragonFly dfbsd 6.5-DEVELOPMENT DragonFly 6.5-DEVELOPMENT #0: Thu Jul  2 06:02:54 UTC 2026     root@dfbsd:/usr/obj/usr/src/sys/X86_64_GENERIC  x86_64",
 "runtime_sec": 90,
 "guest_dirty": 0,
 "build_cmd": "see build.sh",
 "run_cmd": "see run.sh",
 "code_hash": "ec789425057402e248881e4a1fb169f171e95f0a5f557a2f40945c2b9df0e8de",
 "notes": "",
 "recommended_fix": "s/int bn/daddr_t bn/ in msdosfs_mkdir",
 "fix_status": "partial",
 "fix_verdict": "compile_validated (F40FIX build RC=0) and runtime A/B shows the one-liner is necessary but NOT sufficient: on F40FIX the crafted sub-2^31 image (firstcluster=0x20000020) now mounts and mkdir succeeds, while the >=2^31 image still fails mkdir EINVAL with 2 fresh dscheck negative-offset events of the same value - a SECOND 32-bit truncation site remains elsewhere in the msdosfs cluster-offset family (follow-up audit recommended). fix.diff is correct as far as it goes."
}