DF-0769 — hammer_vop_readdir OOB read / info leak via forged direntry data_len

Bug: sys/vfs/hammer/hammer_vnops.c:1728-1738 — hammer_vop_readdir trusts the on-disk int32_t data_len from a B-tree direntry leaf. The only guard is a KKASSERT (no-op on production/INVARIANTS-OFF kernels). A forged data_len=8 underflows the name length data_len - HAMMER_ENTRY_NAME_OFF(=16) to -8, narrowed to uint16_t d_namlen = 65528, driving a bcopy(...,65528) ~49 KB past the 16 KB hammer_buffer → OOB kernel-heap read disclosed to userspace via getdirentries. On GENERIC (INVARIANTS ON) the KKASSERT panics first (local DoS).

How to reproduce (inside the DragonFly guest, as root)

cd /root/df0769
./build.sh                      # builds harness + craft_img
./harness                       # Part 1: deterministic ~49160-byte OOB read proof
./run.sh                        # Part 2: creates 1GB HAMMER image, forges it, mounts, ls /mnt
                                #   on GENERIC #0: PANIC at hammer_vnops.c:1728
                                #   on a FIXED kernel: clean EIO return, no panic

The full panic signature is in panic.txt (from dfbsd-qemu/boot.log). The fix validation (before/after) is in fix_run.log.

Files

• craft_img.c / icrc32.c — image forger (uses the kernel's own iscsi_crc32)
• harness.c — deterministic OOB-read proof (production/INVARIANTS-OFF ceiling)
• fix.diff — git-apply-able runtime bounds check (validated on a single-fix #1 kernel)
• VERDICT.md — full narrative
• build.log / run.log / fix_build.log / fix_run.log / panic.txt / env.txt

DF-0769 — hammer_vop_readdir OOB kernel-heap read / info leak via forged direntry data_len

Verdict

REPRODUCED. On the GENERIC (INVARIANTS-ON) kernel the bug manifests as a kernel panic (local DoS) at hammer_vnops.c:1728. On a production (INVARIANTS-OFF) kernel the same code path performs a ~49 KB out-of-bounds kernel-heap read disclosed to userspace via getdirentries (info leak). The fix.diff runtime bounds check is validated: the panic is gone on a single-fix #1 kernel.

Root cause (confirmed line-by-line)

hammer_vop_readdir (sys/vfs/hammer/hammer_vnops.c) reads each directory entry B-tree leaf and, trusting the on-disk int32_t data_len (hammer_btree.h:175, sourced from untrusted B-tree metadata):

• vnops.c:1728 — KKASSERT(cursor.leaf->data_len > HAMMER_ENTRY_NAME_OFF); This assertion is the only guard. It is a no-op on production kernels (compiled out without INVARIANTS). HAMMER_ENTRY_NAME_OFF = 16 (hammer_disk.h:963, offsetof(hammer_direntry_data, name[0])).
• vnops.c:1737 — cursor.leaf->data_len - HAMMER_ENTRY_NAME_OFF is passed as the d_namlen argument. The expression is computed in int, then implicitly narrowed to uint16_t by vop_write_dirent's prototype (vfs_subr.c:2560). For a forged data_len = 8: 8 - 16 = -8 → (uint16_t)-8 = 65528.
• vfs_subr.c:2575 — bcopy(d_name, dp->d_name, d_namlen) reads 65528 bytes starting at cursor.data->entry.name, which lives inside a 16 KB hammer_buffer->ondisk. The name begins at offset 16 in that buffer, so the bcopy reads 16384 − 16 = 16368 valid bytes then 49160 bytes past the buffer = OOB kernel-heap read.
• vfs_subr.c:2577 — uiomove(dp, len, uio) copies the whole dirent (_DIRENT_RECLEN(65528) = 65552 bytes, including the OOB-read data) to the user getdirentries buffer = info leak.

Why the CRC gate does not stop it

hammer_crc_test_leaf (hammer_crc.h:293) computes the CRC over leaf->data_len bytes of the data (hammer_crc.h:274). For a forged data_len = 8 the CRC covers only the first 8 bytes (the obj_id). An attacker pre-computes data_crc = iscsi_crc32(direntry_data[0:8]), so the CRC test passes — yet the consumer at vnops.c:1737 uses data_len − 16, which is decoupled from the CRC'd length. The containing B-tree node CRC (hammer_crc_get_btree, hammer_crc.h:224) must also be recomputed since data_len lives inside the node; the patcher does both. This was verified empirically: the patcher's self-check (ok=1) confirms the userspace iscsi_crc32 matches the kernel's, and the mount proceeded cleanly with no "CRC FAILED" message.

Reproduction

GENERIC (INVARIANTS-ON) manifestation — panic (this guest's #0 baseline)

1. Image crafting (craft_img.c, links the kernel's own sys/libkern/icrc32.c for userspace): a 1 GB newfs_hammer image is populated with two entries, unmounted, then binary-patched. The patcher scans every 4 KB B-tree leaf node, finds each HAMMER_RECTYPE_DIRENTRY (0x0011) leaf element, sets data_len = 8, recomputes data_crc = iscsi_crc32(data[0:8]), and recomputes the node CRC.
2. Mount (root precondition — acceptable per the threat model: an admin mounts a crafted filesystem image): vnconfig -c vn0 img && mount -t hammer -o nohistory /dev/vn0 /mnt.
3. Trigger (unprivileged): ls /mnt → getdirentries → hammer_vop_readdir → KKASSERT(8 > 16) fails.

Panic signature (from dfbsd-qemu/boot.log, full block in panic.txt):

panic: assertion "cursor.leaf->data_len > HAMMER_ENTRY_NAME_OFF" failed in hammer_vop_readdir at /usr/src/sys/vfs/hammer/hammer_vnops.c:1728
hammer_vop_readdir() at hammer_vop_readdir+0x294
vop_readdir() at vop_readdir+0x6b
kern_getdirentries() at kern_getdirentries+0xdc
sys_getdirentries() at sys_getdirentries+0x24
syscall2() at syscall2+0x11e
Stopped at Debugger+0x7c

The stack names hammer_vop_readdir at vnops.c:1728 reached via the unprivileged getdirentries syscall — exactly the cited path.

Production (INVARIANTS-OFF) manifestation — ~49 KB info leak

harness.c transcribes vnops.c:1737's length arithmetic and vfs_subr.c:2575's bcopy verbatim against a poisoned 16 KB "hammer_buffer" plus adjacent sentinel "heap". Output (deterministic):

forged data_len = 8  =>  d_namlen (uint16_t) = 65528
bcopy(d_name, dp->d_name, 65528): valid in buffer = 16368, OOB read = 49160 bytes
=> ~49160-byte kernel-heap INFO LEAK via unprivileged getdirentries

This is the production ceiling: on INVARIANTS-OFF kernels the KKASSERT is absent, the bcopy runs, and uiomove ships the OOB bytes to userland. The leak exposes neighbouring slab/page data — kernel pointers (KASLR defeat, though KASLR is OFF on this guest regardless), struct ucred * / struct file * pointers, and other kmalloc bucket contents. This is a read-only primitive (the bcopy writes into a freshly kmalloc'd dirent that is immediately kfree'd after uiomove); it does not corrupt kernel state, so no escalation chain applies (valid hard blocker: read-only primitive).

Impact

• GENERIC (default kernel, INVARIANTS ON): local panic / DoS. Trigger: unprivileged getdirentries/ls on a directory of a mounted crafted HAMMER v1 image. Mount is the only root precondition.
• Production (INVARIANTS OFF): ~49 KB kernel-heap info leak per getdirentries call, repeatable, exposing kernel pointers and credential structures. Read-only — no uid=0 chain.

HAMMER v1 is shipped as a loadable module (hammer.ko, auto-loaded on mount); mount_hammer / newfs_hammer are in /sbin. No exotic config required.

Threat model / preconditions

• An admin has mounted (or made mountable) a crafted HAMMER v1 filesystem image and made its directory readable (acceptable precondition, consistent with the audit's realism test). vfs.usermount is OFF, so the mount itself is root; the trigger (getdirentries) is fully unprivileged.
• Alternatively a physically malicious disk / filesystem image presented to the kernel produces the same effect on mount + first directory read.

Exploit chain

None — read-only info-leak / panic primitive. No write, no corruption, so there is no privilege-escalation chain to develop (valid hard blocker per Phase 6: "the primitive is genuinely read-only"). The production ceiling is the ~49 KB kernel-heap disclosure (KASLR defeat + credential-pointer leak).

PoC changes (what was built from scratch)

The finding folder had no PoC; everything was authored during verification: - craft_img.c — HAMMER image forger (locates direntry leaves, sets data_len=8, recomputes leaf data_crc + node crc via the kernel's own iscsi_crc32). Self-validates its CRC against the on-disk values before patching. - icrc32.c — verbatim copy of sys/libkern/icrc32.c (userspace-buildable CRC32C). - harness.c — deterministic transcription of vnops.c:1728-1738 + vfs_subr.c:2560-2577 proving the 49160-byte OOB read (production ceiling). - build.sh, run.sh — exact build/run commands. - fix.diff — runtime bounds check (see below).

Recommended fix (fix.diff)

Add a runtime bounds check before the KKASSERT and the :1737 arithmetic:

if (cursor.leaf->data_len <= HAMMER_ENTRY_NAME_OFF ||
    cursor.leaf->data_len > HAMMER_ENTRY_NAME_OFF + NAME_MAX) {
    error = EIO;
    break;
}

This rejects forged/impossible direntry data_len values with EIO, preventing both the underflow and the OOB read. The KKASSERT is retained as defense-in-depth (now provably-true after the guard). Matches the finding markdown's ## Recommended fix proposal. Validated by Phase 8 (below).

Phase 8 — fix validation (single-fix kernel)

• Baseline #0 (with-src, INVARIANTS ON, unpatched): ls /mnt on the crafted image → panic at hammer_vnops.c:1728 (guest wedged in DDB).
• Single-fix #1 (same tree + fix.diff only, kern.version = 6.5-DEVELOPMENT #1: Sun Jul 5 11:11:26 UTC 2026, sha256 = 56bd513b...): identical crafted image, identical ls /mnt → clean return (total 0, LS_RC=0), no panic, guest healthy across 3 runs. stat /mnt succeeds.

The fix closes the bug: the forged direntry is rejected with EIO before reaching the KKASSERT/underflow, on both GENERIC and production kernels. See fix_build.log (kernel build rc=0) and fix_run.log (post-fix readdir, no panic).