DF-2616 — OOB read/write past the 64KB DIO buffer from crafted hammer2 data_off geometry

Finding: DF-2616 (High, hammer2 bucket) — hammer2_chain_alloc/ hammer2_chain_load_data derive chain->bytes from the radix of the attacker-supplied bref.data_off and never validate the geometry: the offset's alignment to its radix or containment within one 64KB DIO window. The only guard is a KKASSERT in hammer2_io_alloc (hammer2_io.c:126), compiled out without INVARIANTS. A crafted image with a perfectly valid radix but a misaligned / window-crossing offset makes chain->data + chain->bytes overrun the kernel DIO buffer.

What is in this pack

Reproduce

1. Base image: run mkbase.sh on the guest (root), pull base.img to the host.
2. Forge: python3 forge_E.py base.img h2_E_groom.img (needs python3 on host).
3. Push back, then on the guest as root: sh trigger_E.sh.
4. Stock INVARIANTS kernel: mounting variant A (or reading f1 on B/E) panics at hammer2_io.c:126 — see panic_A.txt / panic_B.txt.
5. no-INVARIANTS kernel (options INVARIANTS commented out, make -j6 nativekernel KERNCONF=X86_64_GENERIC): the KKASSERT is gone; the crossed access either page-faults in memmove (ungroomed: fault_B_noinv.txt) or, with the 32-marker grooming, reads/writes the kernel buffer in the adjacent KVA slot (run_E_noinv.log + forensic_E.txt).
6. Fix: git apply fix.diff, rebuild, reboot — mount of A fails cleanly, reading f1 on E fails cleanly with illegal data_off geometry (see fix_run_*.log), no panic, no fault.

Expected observable results

• INVARIANTS kernel: Illegal: ... + panic: assertion "pbase != 0 && ..." at hammer2_io_alloc — deterministic.
• no-INVARIANTS + ungroomed: Fatal trap 12: page fault while in kernel mode ... memmove+0x28 (DDB stop).
• no-INVARIANTS + groomed: no fault; read(2) of f1 returns bytes from beyond the DIO buffer; write(2) plants attacker content through the crossed pointer (on-media proof at image offset 0x200ff05).
• Fixed kernel: clean EINVAL/EIO failures, illegal data_off geometry console message.

DF-2616 — Verdict

REPRODUCED — Missing geometry validation of on-disk bref.data_off in hammer2 chain loading. Impact demonstrated end-to-end:

1. Stock kernel (X86_64_GENERIC, INVARIANTS ON): deterministic panic (mount-time and file-read-time) at the KKASSERT in hammer2_io_alloc (hammer2_io.c:126) — reliable local DoS from a crafted image.
2. Non-INVARIANTS (release-style) kernel: kernel heap OOB read AND write past the 64KB DIO buffer, plus a kernel-mode page fault (DoS) when the adjacent KVA slot is unmapped.

uid=0 escalation was NOT achieved within this run; the write primitive was characterized (below) but the adjacent-object placement could not be controlled deterministically on this guest (see "Exploit chain").

The bug, confirmed in source

• hammer2_chain_alloc (hammer2_chain.c:189-192) derives chain->bytes purely from the low 6 radix bits of the attacker-controlled bref.data_off (HAMMER2_OFF_MASK_RADIX = 0x3F, hammer2_disk.h:461). No geometry check anywhere on the load path.
• hammer2_chain_load_data (hammer2_chain.c:919-1102) only checks the embedded case (data_off & ~MASK == 0, line 938-939), then issues I/O (994-1000) and installs chain->data = hammer2_io_data(dio, data_off) (line 1048, 1100) = bp->b_data + (lbase & 0xFFFF).
• The only geometry guard is hammer2_io_alloc hammer2_io.c:122-126: an unconditional kprintf("Illegal: ...") (so the pass-through is visible on release kernels) followed by a KKASSERT that is compiled out without INVARIANTS. On non-INVARIANTS builds execution continues and chain->data + chain->bytes runs past the end of the 64KB DIO buffer.
• Distinct from DF-0763/DF-2605 (radix magnitude 17-63): DF-2616 fires with a perfectly valid radix (10 or 16) — the violation is the geometry (offset not contained in one 64KB window). Note one refinement to the finding text discovered during verification: hammer2's freemap allocates at 1KB granularity, so a radix-N block at a merely-1KB-aligned offset is legal on real filesystems (the over-strict alignment check in fix v1 broke the root fs boot — see below). The actual unchecked invariant is exactly what hammer2_io.c:126 asserts: pbase != 0 and [lbase, lbase+lsize) within one 64KB window (plus radix ≤ 16).

Demonstrated sinks

• OOB read to userspace: hammer2_strategy_read_completion (hammer2_strategy.c:487) bcopy(data, bp->b_data, focus->bytes) with data = chain->data crossed; read(2) of the crafted file returns bytes from beyond the DIO buffer.
• OOB write: hammer2_write_bp (hammer2_strategy.c:1310-1356): hammer2_io_newnz(... data_off ...) → hammer2_io_data() → bcopy(data, bdata, chain->bytes) writes attacker file data through the crossed pointer — in-window part lands at the crossed media offset (forensically recovered), past-end part lands in the adjacent kernel buffer. The overwrite-in-place path (hammer2_chain_modify, chain.c:1504-1516, CHECK_NONE + modify_tid > pfs_lsnap_tid) keeps the crossed data_off instead of COWing away from it.

Reproduction summary (full logs in this pack)

• panic_A.txt — variant A (sroot bref 0x180fd0a: radix 10 VALID, lbase 0x180fd00, misaligned + crossing), stock kernel: Illegal: 0000000001800000 000000000180fd00+00000400 → panic: assertion ... hammer2_io_alloc at hammer2_io.c:126 at MOUNT time.
• panic_B.txt — variant B (file f1 DATA bref 0x1c0ff0a): mount OK, first read of /mnt/h2/f1 → same panic via hammer2_chain_load_data.
• fault_B_noinv.txt — same variant B on kernel #1 (INVARIANTS off): Fatal trap 12: page fault while in kernel mode ... memmove+0x28 movq (%rsi),%rdx, fault VA 0xfffff8006be66000 = bp->b_data + 0x10000 — the OOB bcopy source ran off the end of the 64KB buffer onto an unmapped page. Kernel stopped in DDB; ssh dead (DoS).
• run_E_noinv.log + forensic_E.txt — variant E on kernel #1 with 32 marker files groomed into their own windows (one live DIO buffer each): the crossed read survived (adjacent KVA slot mapped — returned its content, zeros in this run, to userspace: the OOB read primitive), and the crossed write planted the attacker pattern through the crossed pointer — recovered from the flushed image at media offset 0x200ff05 (inside the crossed window tail, exactly where chain->data pointed). The Illegal: console marker fired on every crossed access (proving the kernel sailed past the compiled-out guard).

Exploit chain (what was and was not achieved)

Demonstrated: crafted image → mount → read(2) returns out-of-bounds kernel-buffer memory; write(2) plants attacker-controlled (LZ4-wrapped) content at a chosen out-of-bounds offset relative to a 64KB kernel buffer (0x300 bytes past its end in the radix-10 forge; up to 0xFF00 with a radix-16 chain — that variant faulted on an unmapped intermediate slot).

NOT achieved: deterministic placement of a chosen victim object in the adjacent KVA slot (so no uid=0). The adjacent slot identity is set by the fixed per-header KVA scheme (vfs_bio.c:638, b_kvabase = vm_map_min(buffer_map) + MAXBSIZE*n) and the per-CPU buffer queues, which the attacker cannot steer precisely from a mounted filesystem in this setup; in the successful run the slot held a clean, zero-filled buffer (mapped but never flushed), so the OOB write could not be recovered from media. The primitives (chosen-offset read/write beyond a kernel buffer object with attacker content) are in place; weaponization requires a victim-object grooming strategy against the buffer cache arena.

Fix validation

• fix v1 (alignment-strict) was WRONG: it rejected legitimate radix-N blocks at 1KB-aligned offsets that real filesystems contain (root fs boot logged dozens of illegal data_off geometry 0x...0b/0c/0d rejections — radix 11/12/13 blocks at 1KB granularity — and degraded the boot). This is itself a verification artifact: the check hooks every chain load.
• fix v2 (fix.diff in this pack) enforces exactly the io.c invariant: radix 0-with-offset / radix > 16 / lbase < 64KB / window-crossing rejected in hammer2_chain_load_data (sets chain->error = HAMMER2_ERROR_CHECK, cleanly failing reads via strategy.c:350 and writes via strategy.c:809), the same check for OPTDATA modify (chain.c:1525+) before hammer2_write_bp can issue I/O, a guard on dedup_off installation, and a widened diagnostic condition in hammer2_io_alloc. See fix_run_*.log for the before/after.