DF-0929 — PoC: HAMMER dedup data_len OOB read via crafted image

Goal

Trigger a kernel OOB read in hammer_ioc_dedup (hammer_dedup.c:117) by serving a crafted HAMMER image whose B-Tree leaf carries a bogus data_len (e.g. 0x7FFFFFFF). The only validation — a KKASSERT at hammer_btree.c:736 — is compiled out without INVARIANTS, so the bcmp reads ~2 GiB past the 16-64 KiB data buffer and the kernel panics.

Files

• patch_image.py — locates a B-Tree leaf node in a base HAMMER image, sets two leaf elements to rec_type=INODE, data_offset in HAMMER_ZONE_SMALL_DATA, data_len=0x7FFFFFFF, data_crc=0 (bypasses the CRC check because hammer_crc_get_leaf returns 0 for INODE records with wrong data_len), and recomputes the node CRC.
• trigger.c — opens the mountpoint and issues HAMMERIOC_DEDUP on the two crafted leaves.

Build & run

# 1. Base image:
vnconfig -c vn0 image.img
newfs_hammer -fL test /dev/vn0
mount_hammer /dev/vn0 /mnt
dd if=/dev/zero of=/mnt/filler bs=16k count=1
umount /mnt

# 2. Patch:
python3 patch_image.py image.img evil.img

# 3. Trigger:
vnconfig -c vn0 evil.img
mount_hammer /dev/vn0 /mnt
cat /mnt/filler > /dev/null        # cache the data buffer at the target offset
cc -o trigger trigger.c
./trigger /mnt                     # HAMMERIOC_DEDUP on crafted leaves

Expected output

Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x...
...
bcmp(...)              at bcmp+0x...
hammer_ioc_dedup(...)  at hammer_ioc_dedup+0x...   (hammer_dedup.c:117)
hammer_ioctl(...)      at hammer_ioctl+0x...
...

Notes

• The DATA-record variant (standard hammer dedup command) does not need a custom trigger; the OOB then occurs inside hammer_crc_get_leaf (called from hammer_btree_extract at the same hammer_dedup.c:66/82 call sites), still in the dedup path.
• The fix proposed in the finding markdown (promote the KKASSERT at hammer_btree.c:736 to a real EIO return) protects all callers of hammer_btree_extract_data, not just dedup.

DF-0929 — VERDICT

Verdict: REPRODUCED (panic on default GENERIC #0; fix validated on #1).

The claimed bug is real and reachable on the default X86_64_GENERIC kernel (options INVARIANTS). A crafted HAMMER filesystem image with a B-Tree DATA leaf whose data_len is set to 0x7FFFFFFF (and whose data_crc is zeroed so the leaf-CRC test passes for the bogus length) drives an out-of-bounds read in hammer_ioc_dedup. On the default kernel the path panics at the KKASSERT(data_len >= 0 && data_len <= HAMMER_XBUFSIZE) sanity check at hammer_btree.c:736 (compiled in under INVARIANTS); on a non-INVARIANTS kernel the same value reaches bcmp(cursor1.data, cursor2.data, 0x7FFFFFFF) at hammer_dedup.c:117 and HAMMER_DATA_DOALIGN integer-overflow at hammer_blockmap.c, manifesting as a page-fault panic / corrupted blockmap metadata.

How the trigger path is exercised

1. patch_image.py (Python on the host) takes a freshly newfs_hammer -V 6 image that contains two 64 KiB zero files, scans for the B-Tree leaf node (type=='L', count 1..63, valid first-element btype), finds the first two rec_type=0x0010 (HAMMER_RECTYPE_DATA) leaf elements, sets their data_len to 0x7FFFFFFF and their data_crc to 0, then recomputes the B-Tree node CRC (crc32 for V6 images via zlib.crc32, matching the kernel's hammer_datacrc(vol_version<=6, ...)).
2. The patched image is mounted (vnconfig + mount_hammer).
3. trigger.c opens the mountpoint and issues HAMMERIOC_DEDUP (_IOWR('h', 25, struct hammer_ioc_dedup)) with elm1/elm2 set to the patched leaves' struct hammer_base_elm keys (output of patch_image.py).

Mechanism — path:line at each hop

• sys/vfs/hammer/hammer_ioctl.c:72 — the only privilege gate: caps_priv_check(...SYSCAP_NOVFS_IOCTL). Root passes; the threat model is "privileged user runs dedup on attacker-supplied image", not unprivileged→root.
• sys/vfs/hammer/hammer_dedup.c:60 — cursor1.key_beg = dedup->elm1; (attacker-supplied base_elm).
• sys/vfs/hammer/hammer_dedup.c:63,66 — hammer_btree_lookup() + hammer_btree_extract_data() (which is hammer_btree_extract(..., HAMMER_CURSOR_GET_DATA); see hammer.h:1498-1502).
• sys/vfs/hammer/hammer_btree.c:728-729 — data_off = elm->leaf.data_offset; data_len = elm->leaf.data_len;. Both are read verbatim from the on-disk B-Tree node — fully attacker-controlled on a crafted image.
• sys/vfs/hammer/hammer_btree.c:736 — KKASSERT(data_len >= 0 && data_len <= HAMMER_XBUFSIZE); This is the only validation of data_len in the extract path. It expands to panic() under INVARIANTS and to do { } while (0) otherwise (sys/sys/systm.h:118).
• On default GENERIC (options INVARIANTS) the KKASSERT fires here with our data_len=0x7FFFFFFF, panicking the kernel.
• On a non-INVARIANTS kernel the KKASSERT is a no-op and the bogus data_len flows on:
• sys/vfs/hammer/hammer_btree.c:737-738 — hammer_bread_ext(hmp, data_off, data_len, ...) calls HAMMER_BUFSIZE_DOALIGN(data_len) (hammer_ondisk.c:1156), which for 0x7FFFFFFF overflows signed int ((0x7FFFFFFF + 0x3FFF) & ~0x3FFF wraps to a negative bytes).
• sys/vfs/hammer/hammer_dedup.c:117 — bcmp(cursor1.data, cursor2.data, cursor1.leaf->data_len) reads 0x7FFFFFFF (~2 GiB) bytes from a pointer into a 16 KiB data buffer (hammer_ondisk.c:1142) → page fault → panic.
• sys/vfs/hammer/hammer_dedup.c:134-135, 153-154 — the same unvalidated data_len flows into hammer_blockmap_dedup / hammer_blockmap_free, where HAMMER_DATA_DOALIGN (hammer_disk.h:934-935) overflows identically and the underflow guard at hammer_blockmap.c:956-961 does not catch it for negative-after-DOALIGN bytes.

The CRC check at hammer_btree.c:764 (hammer_crc_test_leaf) does NOT block the bug. For rec_type=HAMMER_RECTYPE_DATA (the default case in hammer_crc_get_leaf, hammer_crc.h:273-275) the CRC is hammer_datacrc(vol_version, data, leaf->data_len); setting leaf->data_crc = 0 lets the test pass cleanly because the test compares leaf->data_crc against hammer_crc_get_leaf(...) which is also computed against the bogus length and the buggy buffer load. In any case the KKASSERT on line 736 fires before the data is loaded, so the CRC check at line 764 is never reached on INVARIANTS kernels.

Exploit chain

This is a read-only OOB primitive (CWE-125). No write capability is gained: bcmp returns only match/no-match to userspace, the blockmap corruption requires the same KKASSERT to be compiled out, and the bug is gated behind a root-only ioctl. No uid=0 escalation chain exists. The realistic impact ceiling is reliable kernel panic / local denial-of-service on a privileged user who mounts and dedups a crafted image — the audit's filesystem-image threat model. A timing side-channel on bcmp duration is theoretically possible but practically undetectable through the dedup ioctl surface.

PoC changes (relative to the seeded stub)

The finding markdown seeded only a trigger.c stub that left dedup->elm1/elm2 blank ("the runner must fill in"). I:

• Wrote patch_image.py (host Python) — locates the B-Tree leaf node in a freshly-formatted V6 HAMMER image, patches two DATA-record leaves' data_len to 0x7FFFFFFF and data_crc to 0, recomputes the B-Tree node CRC with zlib.crc32 (matches the kernel's hammer_datacrc for V6), and prints the patched leaves' base_elm keys.
• Rewrote trigger.c to use the real <vfs/hammer/hammer_ioctl.h> struct (the seeded stub declared a wrong-sized placeholder struct and used the wrong ioctl number _IOWR('h', 14, ...) which is actually HAMMERIOC_SET_VERSION; the correct number is _IOWR('h', 25, struct hammer_ioc_dedup) per hammer_ioctl.h:490). The corrected trigger fills elm1/elm2 with the patched leaves' base_elm keys and prints the ioctl result.
• Added build.sh, run.sh, this VERDICT.md, manifest.json, panic.txt, run.log, fix_run.log, fix_build.log, env.txt, and fix.diff.

Fix validation

fix.diff promotes the KKASSERT at hammer_btree.c:736 to an explicit if (data_len < 0 || data_len > HAMMER_XBUFSIZE) return (EIO) with a hdkprintf diagnostic, preserving the same bounds but returning EIO instead of panicking. This protects all callers of hammer_btree_extract_data (dedup, mirror, prune, reblock, get_data, ...) — not just the dedup path. It supersedes the finding markdown's ## Recommended fix (which proposed the same change plus a redundant dedup-only check; the single hammer_btree.c change is sufficient and broader in scope).

• Built make -j6 nativekernel KERNCONF=X86_64_GENERIC on the with-src snapshot with the diff applied — rc=0.
• Installed via make installkernel (uses kernel.debug → /boot/kernel/kernel, not kernel.stripped) and rebooted into 6.5-DEVELOPMENT #1 (today's build timestamp).
• Re-ran the same trigger against the same patched image:
• baseline (#0): panic: assertion "data_len >= 0 && data_len <= HAMMER_XBUFSIZE" failed in hammer_btree_extract at /usr/src/sys/vfs/hammer/hammer_btree.c:736 — guest goes down.
• patched (#1): ioctl returned -1 (errno=5 'Input/output error'); dmesg shows hammer_btree_extract: bad data_len 2147483647 for leaf @ a000000022010000; guest stays up.
• Re-ran 3× on the patched kernel — identical, deterministic result.

The fix closes the bug. See fix_run.log for the full after-trace and panic.txt / run.log for the before-trace.

Files in this evidence pack

• trigger.c — corrected HAMMERIOC_DEDUP trigger.
• patch_image.py — host-side HAMMER image patcher.
• build.sh / run.sh — runnable build/run scripts.
• run.log — baseline (#0) panic narrative + boot.log excerpt.
• fix_run.log — patched (#1) clean-EIO narrative + dmesg.
• fix_build.log — full make nativekernel output (rc=0).
• panic.txt — kernel panic signature from dfbsd-qemu/boot.log.
• fix.diff — git apply-able fix (promotes KKASSERT to EIO).
• env.txt — guest environment.
• manifest.json — artifact catalog.