DF-0771 — Missing data_len validation on HAMMER inode load

Title: Missing data_len validation on inode load — crafted image heap OOB Severity: Medium Class: heap OOB read / info leak via crafted filesystem image (mount-time parsing)

Reproduce

Deterministic harness (unprivileged, no kernel effects)

./build.sh && ./run.sh

Builds df0771_harness (userspace; copies the real kernel structs and the verbatim CRC inline logic) and prints both halves of the bug: - CRC gate bypassed for an INODE leaf with data_len != sizeof(inode_data) and data_crc = 0 (hammer_crc.h:267 returns 0, matches on-disk 0). - Struct copy at hammer_inode.c:525 reads 128 bytes unconditionally; with xoff > 16256 it reads past the 16 KiB HAMMER data buffer.

Live kernel path (needs root — threat model is admin mounting attacker media)

sudo ./reproducer-live.sh oob    # OOB variant -> panic on unpatched, EIO on patched
sudo ./reproducer-live.sh        # non-OOB CRC-bypass variant -> mounts on unpatched, EIO on patched

Creates a HAMMER image, corrupts the root-inode B-Tree leaf (data_len=1, data_crc=0, bumps data_offset xoff), recomputes the B-Tree node CRC using the real iscsi_crc32 from sys/libkern/icrc32.c, then mounts.

Expected results

Build / run commands (exact)

• build: cc -O2 -Wall -o df0771_harness df0771_harness.c && cc -O2 -Wall -o corrupt corrupt.c
• run (harness): ./df0771_harness
• run (live, as root): ./reproducer-live.sh oob

Preconditions

• Harness: none (unprivileged userspace).
• Live path: root (vnconfig/newfs_hammer/mount_hammer). vfs.usermount=0 on this guest; the realistic threat is an admin/operator mounting attacker-supplied removable media.

Fix

See fix.diff (validated: single-fix kernel rejects the crafted image with EIO; full before/after in VERDICT.md).

DF-0771 — Missing data_len validation on HAMMER inode load — crafted-image heap OOB read

Verdict: REPRODUCED (info-leak / heap OOB read) — and FIX VALIDATED.

The bug (one paragraph)

hammer_get_inode() (sys/vfs/hammer/hammer_inode.c:525) loads an inode from disk with an unconditional 128-byte struct copy:

523:  if (*errorp == 0) {
524:      ip->ino_leaf = cursor.node->ondisk->elms[cursor.index].leaf;
525:      ip->ino_data = cursor.data->inode;     /* sizeof = 128 bytes */

cursor.data is set by hammer_btree_extract() (hammer_btree.c:737) to the return value of hammer_bread_ext(hmp, data_off, data_len, ...), which is (char *)buffer->ondisk + xoff where xoff = data_off & HAMMER_BUFMASK (hammer_ondisk.c:1116-1170). The buffer is HAMMER_BUFSIZE (16384) bytes. The only length validation on the whole load path is the KKASSERT at hammer_btree.c:734:

KKASSERT(data_len >= 0 && data_len <= HAMMER_XBUFSIZE);   /* <= 65536 */

i.e. the on-disk data_len is never checked against sizeof(struct hammer_inode_data) (128). The struct copy therefore always reads 128 bytes from cursor.data; when the attacker-controlled data_offset's within-buffer xoff is > 16384 - 128 = 16256, the copy runs past the 16 KiB data buffer into adjacent kernel heap.

Why the CRC gate does not catch it

hammer_crc_test_leaf() (hammer_crc.h:294) compares the on-disk data_crc against hammer_crc_get_leaf(). For an HAMMER_RECTYPE_INODE record, hammer_crc_get_leaf() (hammer_crc.h:267-271) does:

case HAMMER_RECTYPE_INODE:
    if (leaf->data_len != sizeof(struct hammer_inode_data))
        return(0);   /* "This shouldn't happen" */

i.e. a wrong-sized INODE record makes hammer_crc_get_leaf() return 0. A crafted image that also sets the on-disk data_crc = 0 then satisfies leaf->data_crc == hammer_crc_get_leaf() as 0 == 0 → the CRC test passes and the wrong-sized record is accepted. (Confirmed in the harness for both vol_version 6 and 7.)

Reproduction — deterministic harness (df0771_harness.c)

A self-contained userspace program that copies the real kernel structs (hammer_inode_data, hammer_btree_leaf_elm) and the verbatim CRC inline logic from hammer_crc.h, then proves both halves of the bug:

sizeof(struct hammer_inode_data) = 128
CRC test for INODE leaf with data_len=1, data_crc=0:
   vol_version=6 -> PASS      vol_version=7 -> PASS
BUG PART 1 CONFIRMED: CRC gate bypassed
TEST 2: xoff=16280, struct copy reads 128 bytes at [16280..16408)
   OOB region = [16384..16408) = 24 bytes past buffer end.
   inode_data.atime (last 8 bytes, all in OOB region) hex: 77 77 77 77 77 77 77 77
BUG PART 2 CONFIRMED: struct copy at hammer_inode.c:525 read 24 bytes
   past the 16 KiB HAMMER data buffer end into adjacent kernel heap.
==== DF-0771 REPRODUCED (info-leak / heap OOB read) ====

Reproduction — live kernel path (reproducer-live.sh)

A real HAMMER filesystem image is created (newfs_hammer), then corrupt (which links the real iscsi_crc32 from sys/libkern/icrc32.c) walks the B-Tree, finds the root-inode leaf (obj_id=1, rec_type=INODE), rewrites data_len = 1, data_crc = 0, bumps data_offset's xoff to 16264 (so the 128-byte struct copy overruns the 16 KiB buffer by 8 bytes — the atime field lands entirely past the end), recomputes the B-Tree node CRC, and writes it back. Mounting the image:

UNPATCHED baseline kernel (6.5-DEVELOPMENT #0): the kernel panics in hammer_get_inode reading atime past the buffer into an unmapped page:

Fatal trap 12: page fault while in kernel mode
fault virtual address  = 0xfffff80061e2a000
fault code             = supervisor read data, page not present
instruction pointer    = 0x8:0xffffffff80938a90
Stopped at hammer_get_inode+0x400:  movq 0x78(%rax),%rax

movq 0x78(%rax),%rax loads the qword at offset 0x78 = 120 — that is the atime field (the last 8 bytes of the 128-byte struct hammer_inode_data), which with xoff = 16264 lands at buffer byte 16264 + 120 = 16384, i.e. the first byte past the buffer. The adjacent page is unmapped → page fault. (Reproduced twice, identical RIP 0xffffffff80938a90.) With a mapped adjacent heap page the read would silently leak heap bytes into inode_data.atime/mtime, returned to userspace via stat()/readlink().

The non-OOB variant (data_len=1, data_crc=0, xoff=0) mounts successfully on the unpatched kernel — proving the CRC bypass accepts a wrong-sized INODE record on the live path; the root inode loads with data copied from the first 128 bytes of the buffer.

Threat model & impact ceiling

• Threat model: crafted HAMMER filesystem image mounted by root / operator / removable-media auto-mounter (vfs.usermount=0 on this guest, so unprivileged mount is not possible; the realistic trigger is an admin mounting attacker-supplied media — the standard mount-time-parsing attacker-controlled-image model used across the audit).
• Primitive class: read-only heap OOB read (info leak). The struct copy is a load, not a store; the bug gives no write/corruption primitive.
• Impact ceiling: kernel heap info leak (KASLR-defeat / pointer-leak class) up to 128 bytes per crafted inode, observable via stat() (st_mtime/st_atime map to the corrupted inode_data.mtime/atime) and via readlink() (ext.symlink[24]). When the adjacent page is unmapped the read manifests as a kernel panic (local DoS by an admin who mounts attacker media).
• Phase-6 escalation: no chain derivable — this is a genuinely read-only primitive (valid hard blocker per Phase 6). There is no write, no UAF, no refcount corruption, no type confusion; only an over-read. No privilege-escalation path exists from a pure info leak without a second, write-capable bug. The leak could assist a separate write primitive (e.g. defeat KASLR for a follow-on bug), but on this guest KASLR is already OFF, so even that assistance is moot here.

Fix (fix.diff)

Minimal, targeted: validate cursor.leaf->data_len == sizeof(struct hammer_inode_data) in hammer_get_inode() before the struct copy at line 525, setting *errorp = EIO (the existing error cleanup at lines 584-592 frees the inode and returns NULL). One logical change, 25 lines (mostly comment), in sys/vfs/hammer/hammer_inode.c.

(Supersedes the finding markdown's proposal, which also suggested changing hammer_crc.h to return (hammer_crc_t)-1. That CRC change is broader and risks side effects on every hammer_crc_get_leaf caller; the consumer-side check at the actual OOB site is the correct, targeted root-cause fix and is sufficient on its own — the wrong-sized record is now rejected at the only place the untrusted data_len feeds a fixed-size struct copy.)

Fix validation (Phase 8 — built, booted, re-run)

• Baseline (#0, unpatched): PoC reproducer-live.sh oob → panic hammer_get_inode+0x400: movq 0x78(%rax),%rax (OOB read into unmapped page). Non-OOB variant mounts successfully (CRC bypass confirmed live).
• Single-fix kernel (#1, Thu Jul 9 17:18:43 2026, sha256 acfae4f3…): same PoC → mount: Input/output error (EIO), guest stays up, dmesg shows the new guard firing: hammer_get_inode: bad inode data_len 1 for obj_id=0000000000000001. Both the OOB and the non-OOB variant are rejected. Fixed.

fix_status: fixed — clean before/after on the same PoC.

Files in this evidence pack