DF-3040 — Unbounded HAMMER_UNDO_INDEX indexes vol0_undo_array[128] out of bounds: kernel heap OOB read at attacker-chosen offset on mount of a crafted HAMMER1 image

Kernel: DragonFly 6.5-DEVELOPMENT #0 (X86_64_GENERIC, INVARIANTS), sys/vfs/hammer File under audit: sys/vfs/hammer/hammer_ondisk.c (pass 2); root cause sink in hammer_undo_lookup() / hammer_xlate_to_undo (hammer_disk.h).

Reproduce

# guest (root), after pushing undo_craft.c/build.sh/run.sh:
sh build.sh                       # cc undo_craft + newfs_hammer 12G base.img
sh run.sh 0x400000000             # idx 2048  -> read at bp+17288
sh run.sh 0x4000000000            # idx 32768 -> read at bp+263048
# expected (stock INVARIANTS kernel):
#   Fatal trap 12: page fault, supervisor read data, page not present
#   Stopped at hammer_undo_lookup+0x84: addq 0x388(%rcx,%rdx,8),%rbx
#   (guest wedged at db>; the mount never completes)

The faulting instruction is the vol0_undo_array[idx] load itself: 0x388 = 904 = offsetof(struct hammer_volume_ondisk, vol0_undo_array), %rdx = attacker-chosen index (short(zone3)/HAMMER_BIGBLOCK_SIZE), and the fault VA is 904 + idx*8 bytes into the 16KB rootvol bp mapping — i.e. past its end.

Root cause

• hammer_get_buffer() (hammer_ondisk.c:688-689) dispatches zone-3 offsets to hammer_undo_lookup() (hammer_undo.c:58-76).
• The only bounds applied anywhere on the undo path are:
• hammer_recover_stage1 (hammer_recover.c:232): first_offset > alloc_offset || next_offset > alloc_offset → EIO — but alloc_offset itself comes from the attacker-crafted vol0_blockmap[3] in the root volume header;
• KKASSERT(zone3_off < undomap->alloc_offset) (hammer_undo.c:70) — same attacker-controlled reference, and INVARIANTS-only.
• hammer_xlate_to_undo() (hammer_disk.h:827-829) then computes vol0_undo_array[HAMMER_UNDO_INDEX(zone3)] where HAMMER_UNDO_INDEX = short(zone3) / HAMMER_BIGBLOCK_SIZE (8MB). The array has exactly HAMMER_MAX_UNDO_BIGBLOCKS = 128 entries (hammer_disk.h:512,789); the kernel never checks the index against it (the constant is not referenced anywhere in sys/). short(zone3) spans 2^52, so idx spans 2^29 → the load can be aimed up to ~4GB past the 16KB header buffer.
• Trigger path: mount_hammer → hammer_mount (vfsops.c:671 copies the crafted blockmap) → hammer_recover_stage1 version-4 backscan (recover.c:257-263) → hammer_recover_scan_rev → hammer_bread(zone3) (recover.c:798) → hammer_get_buffer → hammer_undo_lookup → OOB load.

Impact: crafted-image mount-time kernel OOB read (CWE-125) at an attacker-chosen offset up to ~4GB from the header bp. On INVARIANTS guests this manifests as the observed page-fault panic (deterministic local DoS from a root-mounted image; vfs.usermount=1 makes it unprivileged). On production (non-INVARIANTS) kernels the OOB value is used as a zone-2 offset; the read itself stays in-kernel (no demonstrated disclosure of the OOB bytes to userspace — the value only steers which device block is subsequently read). Mount of a crafted image requires root (or usermount), consistent with the DF-0797/DF-0798 threat model.

Fix validation

• fix.diff (authored against the read-only audit tree; applied only to the guest's /usr/src copy): reject zone3_off >= HAMMER_ENCODE_UNDO(128 * 8MB) in hammer_undo_lookup() with EIO before hammer_xlate_to_undo().
• make nativekernel KERNCONF=X86_64_GENERIC → OK (fix_build.log); rebooted into kernel #1 (Sat Sep 5 16:07:13 UTC 2026).
• Re-ran the exact PoC (run.sh 0x4000000000) on the fixed kernel: mount: Input/output error; console shows Unable to read UNDO TAIL at 3000003ffffffff8 / recovery failure during seqno backscan / Failed to recover HAMMER filesystem on mount; no panic, guest stays up (fix_run.log).
• Regression on the fixed kernel: stock newfs_hammer image mount + create + rm + sync + umount cycle is clean (freemap_probe.sh, also refutes the DF-3011 "off-by-8" environmental artifact — see run.log).

Artifacts

• undo_craft.c — image forger (patches vol0_blockmap[3] only; no CRC fixup needed because the kernel never verifies vol_crc — see DF-3042)
• build.sh / run.sh / freemap_probe.sh
• run.log — both baseline runs + console transcripts (full console in panic_idx2048.txt, panic_idx32768.txt)
• fix.diff, fix_build.log, fix_run.log
• manifest.json, verdict.json

DF-3040 VERDICT — unbounded HAMMER_UNDO_INDEX → vol0_undo_array OOB kernel heap read

Status: REPRODUCED (baseline, twice, fresh boots) · FIXED (fix.diff validated on a rebuilt kernel).

What was claimed vs what happened

The pass-2 audit of sys/vfs/hammer/hammer_ondisk.c found that the zone-3 (undo) dispatch at hammer_ondisk.c:688-689 reaches hammer_undo_lookup() (hammer_undo.c:58-76), whose only offset bound — KKASSERT(zone3_off < undomap->alloc_offset) — references the same attacker-crafted vol0_blockmap[3] that supplies the offset. The final translation hammer_xlate_to_undo (hammer_disk.h:827-829) indexes vol0_undo_array[HAMMER_UNDO_INDEX(zone3)] with HAMMER_UNDO_INDEX = short(zone3)/8MB; the array holds 128 entries (HAMMER_MAX_UNDO_BIGBLOCKS, hammer_disk.h:512) and no code in sys/ compares the index against 128. The mount path reaches this with a fully crafted offset: hammer_recover_stage1 (hammer_recover.c:232) only checks first/next against the attacker's own alloc_offset, then the version-4 backscan (recover.c:257-263 → :798) issues hammer_bread() on the crafted zone-3 offset.

Two baseline runs on the stock INVARIANTS kernel (#0, Jul 2 2026), each after a fresh vm.sh reset with-src, mounting a newfs_hammer image whose vol0_blockmap[3] was patched by undo_craft:

The faulting instruction addq 0x388(%rcx,%rdx,8),%rbx is the vol0_undo_array[idx] load (0x388=904=offsetof(vol0_undo_array)); the fault VAs are past the 16KB rootvol bp mapping, at distances that track the attacker-chosen index exactly. The index is image-controlled up to 2^29 (~4GB reach). Both runs wedged the guest at db> (kernel panic — guest down), i.e. a deterministic DoS on mount of the crafted image.

Why not higher impact

The OOB value is consumed as a zone-2 offset (result_offset), not copied to userspace. On INVARIANTS kernels the subsequent KKASSERT(hammer_is_zone_raw_buffer(...)) (hammer_ondisk.c:703) or — as observed — the unmapped OOB load itself panics first. On production (non-INVARIANTS) kernels the garbage zone-2 offset leads to hammer_get_volume() ENOENT or an EIO device read in the common case; there is no demonstrated exfiltration channel for the OOB-read bytes. The primitive is an attacker-aimed kernel read (CWE-125) whose practical impact on this guest is the panic. Note the in-bounds half of the same bug: for idx in [128,1792] the load stays inside the 16KB bp but past the on-disk struct — the attacker then knows the value (it is their own image bytes at LBA1+), giving a fully controlled zone-2 offset bypassing the 128-entry map.

Severity Medium: mount-time (root/usermount preconditions, same as DF-0797 / DF-0798), memory-safety proven, disclosure not demonstrated, deterministic panic on default INVARIANTS builds.

Fix validation (mandatory: memory-corruption class reproduced)

fix.diff bounds zone3_off to the on-disk format's supported undo range in hammer_undo_lookup() (EIO before hammer_xlate_to_undo); authored against the read-only audit tree (git apply --check clean), applied only to the guest's /usr/src copy, make nativekernel KERNCONF=X86_64_GENERIC → OK, rebooted into kernel #1 (Sat Sep 5 16:07:13 UTC 2026):

• Baseline reproduced: 2/2 panics on stock kernel #0 (run.log, panic_idx*.txt).
• Patched kernel: same PoC (run.sh 0x4000000000) → mount: Input/output error, console Unable to read UNDO TAIL … recovery failure during seqno backscan / Failed to recover HAMMER filesystem on mount, guest up (fix_run.log).
• Regression: stock newfs_hammer mount + create/rm/sync/umount clean on the fixed kernel (freemap probe in run.log).

Environmental check performed (priority 7 of this audit)

DF-3011's note about KKASSERT(layer2->zone==zone) (hammer_blockmap.c:832) and a suspected "off-by-8 between the on-disk layer1 table and the blockmap root" is not reproducible on stock images: a plain newfs_hammer image goes through mount + btree-node alloc/free (file create, delete, sync) without tripping any freemap KKASSERT, on both the stock and fixed kernels. The artifact seen in DF-3011 came from the deepforge grafting (nodes allocated at vol0_blockmap[8].next_offset without matching freemap layer2 zone bits), not from a kernel decode bug. No finding filed.

Related-but-distinct (not re-reported)

DF-0797 (vol_no → volume_map OOB write) and DF-0798 (node in-buffer offset OOB read during CRC) remain unfixed in-tree, as does DF-0776's proposed count/type validation (hammer_load_node/hammer_btree.c carry only KKASSERTs).