{
 "finding_id": "DF-3215",
 "status": "reproduced",
 "reproduced": 1,
 "impact": "panic",
 "confidence": "certain",
 "verdict": "REPRODUCED on the stock INVARIANTS guest: an unprivileged user (nobody) running a write()+fsync() loop on a HAMMER v7 filesystem with the mkhammer-supported minimum 8MB UNDO/REDO FIFO panics the kernel (panic: hammer_generate_redo: insufficient UNDO/REDO FIFO space for redo!) within ~6 rounds / ~90s. Root cause: hammer_generate_redo (sys/vfs/hammer/hammer_redo.c:90-91) panics instead of failing or waiting, and there is NO backpressure anywhere on the frontend REDO path \u2014 default vfs.hammer.fsync_mode=3 takes the REDO fast-fsync (hammer_vnops.c:225-246) which re-arms the 4MB per-inode budget forever, while FIFO space is only reclaimed by flusher finalize cycles whose on-disk first_offset lags a full cycle behind (hammer_flusher.c:736-800). The panic actually fired in the trailing REDO_SYNC emission (hammer_redo.c:288-291) which runs after the callers own record was laid. Default 512MB FIFO NOT overflowed on this QEMU guest (page-cached virtio reclaim kept up over 3.84GB of laid REDO \u2014 see run.3.log), so the demonstrated precondition is a small-undo filesystem. Not memory corruption: impact is a deterministic unprivileged local DoS. Fix validated: hpanic->ENOSPC + FIFO-pressure REDO gate in the write path; patched kernel completes the identical trigger with no panic and a healthy mount.",
 "exploit_chain": "",
 "evidence": [
  "panic.txt \u2014 serial-console panic: panic: hammer_generate_redo: insufficient UNDO/REDO FIFO space for redo! with double hammer_generate_redo frame + hammer_vop_write/vn_write/kern_pwritev",
  "run.log \u2014 baseline V2 run as nobody: rounds 1-6 progress into the 8MB FIFO, then session death (panic)",
  "run.2.log \u2014 patched kernel (fix.diff): identical trigger, all 30 rounds complete, guest up, no panic",
  "run.3.log \u2014 V1 default-512MB-FIFO negative: 2.56-3.84GB of REDO laid unprivileged, no overflow on this guest",
  "setup_v2.sh / redo_fill.c \u2014 the vn-image harness (newfs_hammer -f -u 8m) and the unprivileged trigger",
  "fix.diff \u2014 git-apply clean against sys/: hpanic -> graceful ENOSPC + write-path FIFO-pressure gate"
 ],
 "kernel_refs": [
  "sys/vfs/hammer/hammer_redo.c:90",
  "sys/vfs/hammer/hammer_redo.c:97-277",
  "sys/vfs/hammer/hammer_redo.c:288-291",
  "sys/vfs/hammer/hammer_undo.c:477-512",
  "sys/vfs/hammer/hammer_flusher.c:736-800",
  "sys/vfs/hammer/hammer_vnops.c:225-246",
  "sys/vfs/hammer/hammer_vnops.c:743-754",
  "sys/vfs/hammer/hammer_vfsops.c:100",
  "sbin/hammer/ondisk.c:745-780"
 ],
 "poc_changes": "Authored fresh (no seed): redo_fill.c (first fsync enables HAMMER_INODE_REDO, then write+fsync pairs re-arm the 4MB budget); fixed newfs_hammer -u suffix (8m not 8388608), vn image path moved off the 975MB tmpfs, mount|grep label fix. Two V1 default-config variants added to probe the 512MB FIFO race (negative on this guest).",
 "attempts": 3,
 "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": 92,
 "guest_dirty": 0,
 "build_cmd": "cc -O2 -o /tmp/df3215/redo_fill /tmp/df3215/redo_fill.c",
 "run_cmd": "sh /tmp/df3215/setup_v2.sh && su -m nobody -c /tmp/df3215/redo_fill /mnt/h1/scratch 1 1048576 30",
 "code_hash": "cec17b4a82d37cd5ded1c4b7be68681521dd98fea37a403c605a486bb517317e",
 "notes": "Impact classification: panic == unprivileged local DoS (Medium). Small-undo precondition is a legal mkhammer configuration (-f -u 8m; mkhammer only warns), and the kernel performs no FIFO-size validation at mount, so crafted images with tiny FIFOs are equally exposed. Default-512MB-FIFO variant plausible on real (HDD-class) storage but not demonstrated on the QEMU guest. The sibling hpanic in hammer_generate_undo (hammer_undo.c:136-137) is the same defect class on the flusher-side path. Guest was reset to the clean-source snapshot after validation.",
 "recommended_fix": "Replace the redo.c hpanic with a graceful ENOSPC failure and gate REDO generation in hammer_vop_write on FIFO headroom (disable REDO under pressure, the existing degradation idiom); see findings/poc/DF-3215/fix.diff.",
 "fix_status": "fixed",
 "fix_kernel_uname": "DragonFly dfbsd 6.5-DEVELOPMENT DragonFly 6.5-DEVELOPMENT #1: Tue Sep 8 15:56:24 UTC 2026 root@dfbsd:/usr/obj/usr/src/sys/X86_64_GENERIC x86_64",
 "fix_baseline_reproduced": 1,
 "fix_patched_reproduced": 0,
 "fix_verdict": "fix.diff applied to the guests /usr/src copy (repo sys/ untouched); make nativekernel KERNCONF=X86_64_GENERIC + installkernel, reboot into kernel #1. Baseline (stock #0): panic at round 6. Patched (#1): identical run.sh completes all 30 rounds in ~1s, no panic, guest and mount healthy (run.2.log). The FIFO-pressure gate disables REDO before exhaustion; the ENOSPC backstop covers ungated callers (REDO_TRUNC, backend TERMs, trailing SYNC) and was not directly exercised by this run.",
 "fix_evidence": "run.2.log (patched run, no panic); build.log (kernel install completed); fix.diff"
}