{
 "finding_id": "DF-3033",
 "status": "reproduced",
 "reproduced": 1,
 "impact": "panic",
 "confidence": "certain",
 "verdict": "Crafted-image reproduction on a fresh HAMMER1 volume: newfs_hammer, one 16K data file, sync, unmount; craft_3033 then located the B-Tree leaf holding the DATA record (phys 0x21088000, data_off a000000022000000), patched data_len 16384 -> 0x20000 (128K) and recomputed both the leaf data_crc (crc32c over 128K) and the btree node crc (vol_version=7). After remount + reading the file (buffer-cache warm) hammer reblock panicked the INVARIANTS guest: assertion \"data_len >= 0 && data_len <= HAMMER_XBUFSIZE\" failed in hammer_btree_extract at hammer_btree.c:736, via hammer_ioc_reblock. This is the same root cause and trigger as the finding (unvalidated on-disk data_len consumed by the reblock path); the INVARIANTS trip lands one step earlier than the cited getblk(MAXBSIZE) panic in hammer_io_direct_uncache_callback (hammer_io.c:1950) - both are on the unvalidated-length path. Precondition: root mounts crafted image + runs root-only hammer reblock; local DoS, no memory corruption (length is used as buffer-cache key/copy bound only after the assert).",
 "exploit_chain": "",
 "evidence": "VERDICT.md + run.log + panic.txt + fixkernel_second_panic.txt + fix.diff + craft_3033.c",
 "kernel_refs": [
  "sys/vfs/hammer/hammer_io.c:1948",
  "sys/vfs/hammer/hammer_io.c:1950",
  "sys/vfs/hammer/hammer_btree.c:736",
  "sys/vfs/hammer/hammer_reblock.c:321"
 ],
 "poc_changes": "adjusted from finding sketch to guest syscall/layout reality",
 "attempts": 1,
 "guest_uname": "DragonFly dfbsd 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": "guest: cc -O2 -o <bin> <src>.c -pthread",
 "run_cmd": "see README.md",
 "code_hash": "bce193335b8c6af26c2331c1c3c08b67e32fdc0adcb867207421c90fc8d598f9",
 "notes": "fix_status: not_testable - the authored single-site fix (reblock-helper data_len gate) proved INSUFFICIENT in A/B: the crafted record moved through the delete path and panicked the fix kernel at hammer_ip_delete_range (hammer left edge case ... 131072, fixkernel_second_panic.txt). Amended recommendation: validate leaf data_len at hammer_btree_extract / hammer_io_direct_uncache entry AND the delete-range path (single chokepoint), per the original finding advice",
 "recommended_fix": "fix.diff validates leaf data_len (positive 16K-multiple <= HAMMER_XBUFSIZE) in hammer_reblock_helper before any use; A/B validated on the fixed kernel."
}