DF-0776 — Missing production bounds validation on HAMMER B-tree node count/type

Verdict

REPRODUCED + FIX VALIDATED.

On the GENERIC (INVARIANTS-ON) kernel the bug manifests as a kernel panic (local DoS) at hammer_btree.c:1278 on the first btree_search of a forged node. On a production (INVARIANTS-OFF) kernel the same forged node drives deterministic OOB kernel-heap read (info leak, up to ~8 KB per access via hammer_btree_search_node + leaf loop) and OOB kernel-heap write (up to ~8.8 KB via hammer_btree_insert's bcopy element shift). The fix.diff adds runtime validation of type/count in hammer_load_node plus error propagation through hammer_init_cursor/hammer_get_inode; the panic is gone on a single-fix #1 kernel (mount returns EIO, guest stays up, normal mounts unaffected).

Reproduce

./build.sh                      # builds craft_img (forger) + harness (OOB proof)
./run.sh                        # harness + image creation + forge + mount + ls

The mount step is the acceptable root precondition (admin mounts a crafted image). The ls/stat trigger is unprivileged (in the production/INVARIANTS-OFF case where mount succeeds and readdir hits the loops). On GENERIC, the panic fires at mount-time (the mount's own root-inode btree lookup is the first hit).

Expected output

• GENERIC #0 (unpatched, INVARIANTS ON): panic: assertion "node->count <= HAMMER_BTREE_LEAF_ELMS" failed in btree_search at hammer_btree.c:1278 — guest wedges in DDB. See panic.txt.
• Production (INVARIANTS OFF): harness shows the OOB extents (read + write).
• Fix #1: mount: Input/output error (EIO), dmesg shows hammer_load_node: B-TREE NODE @ ... BAD type=76 count=200, no panic, guest healthy.

DF-0776 — Missing production bounds validation on HAMMER B-tree node count/type

Verdict

REPRODUCED. FIX VALIDATED (status: fixed). On the GENERIC (INVARIANTS-ON) kernel the bug manifests as a kernel panic (local DoS) at hammer_btree.c:1278. On a production (INVARIANTS-OFF) kernel the same forged node drives deterministic OOB kernel-heap read (info leak) and OOB kernel-heap write (corruption). The fix.diff runtime validation closes both; the panic is gone on a single-fix #1 kernel.

Root cause (confirmed line-by-line)

HAMMER B-tree nodes are read from disk into struct hammer_node_ondisk (hammer_btree.h:218), which contains a fixed-size element array elms[HAMMER_BTREE_LEAF_ELMS] = elms[63] (hammer_btree.h:244). The node-header fields count (int32_t, offset 16) and type (uint8_t, offset 20) are attacker-controllable via the on-disk image.

The load path validates ONLY the CRC, never count/type: - hammer_load_node (hammer_ondisk.c:1269): loads the node buffer, then at :1313-1325 runs only hammer_crc_test_btree() (hammer_crc.h:237). If the CRC passes, HAMMER_NODE_CRCGOOD is set and the node is handed to callers with count/type trusted unvalidated. - hammer_crc_test_btree computes CRC32C (iscsi_crc32, sys/libkern/icrc32.c) over [4:4096). CRC32C is not crypto-secure — an attacker recomputes it after forging count, so the CRC gate is forgeable. (Userland hammer show validates count at cmd_show.c:264-289; the kernel does NOT.)

All in-kernel bounds checks are KKASSERT (no-op on production): - hammer_btree_insert :818 — KKASSERT(node->count < HAMMER_BTREE_LEAF_ELMS) — no-op on production. - btree_search :1278 — KKASSERT(node->count <= HAMMER_BTREE_LEAF_ELMS) — no-op on production. - hammer_btree_delete :900-901 — KKASSERT(i >= 0 && i < ondisk->count) — no-op.

OOB READ (btree_search, reached by any ls/stat/readdir): - :1089 hammer_btree_search_node() (:1390-1413) does a binary search with s = node->count; for count=200 the midpoint indexes elms[100], elms[150], etc. — up to 8320+ bytes past elms[] into adjacent kernel heap. - :1290 leaf loop while (i < node->count) { elm = &node->elms[i]; ... } walks elms[0..199], reading elms[63..199] OOB. - :1090 internal loop while (i <= node->count) — same OOB for internal nodes.

OOB WRITE (hammer_btree_insert :819-824, reached by any create/mkdir):

if (i != node->count)
    bcopy(&node->elms[i], &node->elms[i+1], (node->count - i) * sizeof(*elm));

With count=200, i=0: bcopy of (200-0)*64 = 12800 bytes starting at elms[1], writing 8832 bytes past the 4096-byte node buffer into kernel heap.

Why the CRC gate does not stop it

The node CRC covers [4:4096) — INCLUDING count. The attacker forges count=200, then recomputes crc = iscsi_crc32(node[4:4096]). The recomputed CRC matches, so hammer_crc_test_btree passes. The self-check in craft_img.c confirms this: the original node CRC matches our iscsi_crc32 implementation (crc ok=1) before forging, proving the CRC implementation is correct.

Trigger

1. Root creates a small HAMMER v1 image (newfs_hammer), populates entries, unmounts (acceptable precondition).
2. craft_img binary-patches every leaf node's count to 200 and recomputes the node CRC32C.
3. Root mounts the crafted image; unprivileged ls/stat/readdir triggers btree_search → OOB. On GENERIC, the mount's own root-inode lookup is the first hit → panic at mount time.

GENERIC #0 reproduction (panic)

panic: assertion "node->count <= HAMMER_BTREE_LEAF_ELMS" failed in btree_search
       at /usr/src/sys/vfs/hammer/hammer_btree.c:1278
Trace beginning at frame 0xfffff801166db218
btree_search.constprop.12() at btree_search.constprop.12+0x11f8
hammer_btree_lookup() at hammer_btree_lookup+0x65
hammer_get_inode() at hammer_get_inode+0x280
hammer_vfs_vget() at hammer_vfs_vget+0x73
hammer_vfs_mount() at hammer_vfs_mount+0xb5e

Reproduced 2× on fresh with-src resets. See panic.txt.

Production OOB characterization (harness)

harness.c transcribes the exact vulnerable loops verbatim with a poisoned allocator (4096-byte node buffer + adjacent-heap sentinels): - OOB READ: hammer_btree_search_node binary search accesses elms[100], elms[150], elms[175] etc.; leaf loop reads elms[196..199] = 256 bytes past the 4096-byte node buffer. (With a smaller search_node starting index, the leaf loop alone can sweep elms[63..199] = 8768 bytes OOB.) - OOB WRITE: hammer_btree_insert bcopy shifts (200)*64 = 12800 bytes, 8832 bytes past the 4096-byte node buffer into adjacent kernel heap.

Impact ceiling / exploit chain

• GENERIC (INVARIANTS ON, default): panic / local DoS at mount or first btree access. The KKASSERT catches the OOB before it lands. Impact: panic.
• Production (INVARIANTS OFF): OOB kernel-heap read (info leak) + OOB kernel-heap write (corruption). The read discloses adjacent slab data (potential KASLR defeat / credential-pointer leak); the write corrupts adjacent kernel objects.

Escalation attempt (Phase 6): The OOB write is attacker-triggered via unprivileged create/mkdir on a mounted crafted image. However, on this guest the default kernel is GENERIC (INVARIANTS ON), where the KKASSERT fires before the write — so the write primitive is only reachable on a non-default (noinv) kernel. Per the bright-line rule, an INVARIANTS-OFF-only escalation is a non-default-kernel result. On GENERIC, the demonstrated impact is panic (DoS). The production OOB write primitive is characterized by the harness; a full uid=0 chain on noinv would require (1) mounting the crafted image (root precondition), (2) grooming the HAMMER buffer-adjacent slab to place a victim object (e.g. struct file / struct ucred) next to the target B-tree node, (3) triggering hammer_btree_insert to overwrite the victim via the bcopy shift, (4) forging a credential (no SMAP/SMEP) — but this is blocked by INVARIANTS on the default kernel. Reported impact: panic on GENERIC; OOB read/write characterized on production.

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 leaf nodes, sets count=200, recomputes node CRC via the kernel's own iscsi_crc32). Self-validates its CRC against on-disk values before patching. - icrc32.c — verbatim copy of sys/libkern/icrc32.c (userspace CRC32C). - harness.c — deterministic transcription of hammer_btree_search_node (:1390), btree_search leaf loop (:1290), and hammer_btree_insert bcopy (:819-824), proving the OOB read + write extents (production ceiling). - build.sh, run.sh — exact build/run commands. - fix.diff — 3-file runtime validation + error propagation (see below).

Recommended fix (fix.diff)

Three changes (all in sys/vfs/hammer/): 1. hammer_ondisk.c (hammer_load_node, after the CRC check): validate type (must be LEAF or INTERNAL) and count (0 <= count <= max_elements(type)) using the existing hammer_node_max_elements() inline (hammer_btree.h:283). Set HAMMER_NODE_CRCBAD + print a diagnostic if invalid — the node is then rejected with EIO exactly as a bad-CRC node is. 2. hammer_cursor.c (hammer_init_cursor:200-202): replace KKASSERT(error == 0) with proper error propagation (if (error) hammer_done_cursor(cursor); return(error);) so a rejected root node fails gracefully instead of panicking. 3. hammer_inode.c (hammer_get_inode:499): capture and check the return of hammer_init_cursor (was discarded), bailing with *errorp on failure.

Supersedes the finding markdown's proposal (which suggested only the hammer_ondisk.c validation; the cascading cursor/inode fixes are required for graceful rejection on GENERIC). Validated by Phase 8 (below).

Phase 8 — fix validation (single-fix kernel)

• Baseline #0 (with-src, INVARIANTS ON, unpatched): mount of the crafted image (leaf count=200, CRC forged) → panic at hammer_btree.c:1278 (panic.txt). Reproduced 2× on fresh resets.
• Single-fix #1 (same tree + fix.diff only, kern.version = 6.5-DEVELOPMENT #1: Sun Jul 5 12:23:02 UTC 2026): identical crafted image, identical mount command → mount: Input/output error (EIO), no panic. dmesg shows hammer_load_node: B-TREE NODE @ 8000000021000000 BAD type=76 count=200 (type 76 = 'L' = LEAF; count 200 detected and rejected). Deterministic across 3 runs. Guest healthy after each. A clean (unforged) HAMMER image mounts and operates normally on the same #1 kernel — the fix does not break normal operation.

Kernel references (confirmed during verification)

• sys/vfs/hammer/hammer_ondisk.c:1313-1325 — CRC-only node validation (no count/type check)
• sys/vfs/hammer/hammer_ondisk.c:1269 — hammer_load_node (the load path)
• sys/vfs/hammer/hammer_btree.c:1278 — KKASSERT(node->count <= HAMMER_BTREE_LEAF_ELMS) (panic site)
• sys/vfs/hammer/hammer_btree.c:818 — KKASSERT(node->count < HAMMER_BTREE_LEAF_ELMS) (insert)
• sys/vfs/hammer/hammer_btree.c:819-824 — OOB WRITE (bcopy shift)
• sys/vfs/hammer/hammer_btree.c:1089-1090 — OOB READ (internal loop + search_node)
• sys/vfs/hammer/hammer_btree.c:1289-1290 — OOB READ (leaf loop + search_node)
• sys/vfs/hammer/hammer_btree.c:1390-1413 — hammer_btree_search_node (binary search OOB)
• sys/vfs/hammer/hammer_btree.h:215-216,244 — HAMMER_BTREE_LEAF_ELMS=63, elms[63]
• sys/vfs/hammer/hammer_btree.h:283-292 — hammer_node_max_elements() (fix uses this)
• sys/vfs/hammer/hammer_crc.h:237-247 — hammer_crc_test_btree (forgeable CRC32C)
• sys/vfs/hammer/hammer_cursor.c:200-202 — cascading KKASSERT(error==0) (fix #2)
• sys/vfs/hammer/hammer_inode.c:499 — discarded hammer_init_cursor return (fix #3)