DF-0798 — Missing bounds check on B-Tree node in-buffer offset (OOB heap read in CRC validation)

Severity: Low Class: Heap OOB read in filesystem image parsing (no writes, no control flow hijack) File: sys/vfs/hammer/hammer_ondisk.c:1306-1315 Threat model: an administrator is tricked into mounting an attacker-crafted HAMMER filesystem image. (Unprivileged users can also do this if vfs.usermount=1 and a root-created vnode/image is chowned to them — the audit's standard acceptable precondition.)

How to run

The PoC must be run as root (mounting any filesystem requires it). This matches the threat model: a malicious filesystem image being mounted.

ssh dfbsd                        # root shell on guest
cd /root/poc/DF-0798             # wherever you placed it
./build.sh                       # compile the byte-patching helper
./run.sh                         # build a HAMMER image, patch, mount, observe

What it does

1. Creates a small valid HAMMER filesystem image (/build/df0798.img, 4 GB sparse).
2. Mounts it briefly RW and populates it with a couple of files so the B-Tree root node is allocated and vol0_btree_root is set in the volume header.
3. Unmounts.
4. Reads the current vol0_btree_root (8-byte little-endian at struct offset 240 in the on-disk volume header — see sys/vfs/hammer/hammer_disk.h:776) and ORs its low 14 bits with 0x3FFC. This keeps the offset pointing at the SAME 16 KiB HAMMER buffer as the legitimate root (the high bits and the buffer-select bits are unchanged), so the freemap lookup still passes.
5. Attempts to mount the patched image read-only. The very first B-Tree lookup (rooted at vol0_btree_root — sys/vfs/hammer/hammer_cursor.c:160) calls hammer_get_node() → hammer_load_node(), which executes the vulnerable pointer arithmetic and the CRC validation read.

Vulnerable code path (confirmed by source trace)

sys/vfs/hammer/hammer_ondisk.c:1306:

node->ondisk = (void *)((char *)buffer->ondisk +
                        (node->node_offset & HAMMER_BUFMASK));

HAMMER_BUFMASK = 16383 (hammer_disk.h:72), so node_offset & HAMMER_BUFMASK can be 0..16383. There is no check that the resulting pointer plus the node size stays within the 16384-byte buffer.

sys/vfs/hammer/hammer_ondisk.c:1315 then calls hammer_crc_test_btree(hmp->version, node->ondisk), which at sys/vfs/hammer/hammer_crc.h:227 runs:

hammer_datacrc(vol_version, &node->crc + 1, HAMMER_BTREE_CRCSIZE);

HAMMER_BTREE_CRCSIZE = sizeof(struct hammer_node_ondisk) - sizeof(hammer_crc_t) = 4096 - 4 = 4092 (hammer_btree.h:247).

So with node_offset & HAMMER_BUFMASK = 0x3FFC, the CRC engine reads bytes [0x3FFC+4 .. 0x3FFC+4+4092) = [0x4000 .. 0x5000-4) of the buffer's KVA, i.e. up to 4092 bytes entirely past the end of the 16384-byte buffer into adjacent kernel heap/buffer-cache memory.

Why it doesn't reproduce visibly (impact ceiling)

hammer_crc_test_btree reads the bytes and only compares the resulting CRC against node->crc. The bytes themselves are never copied to userspace. Two outcomes are possible:

• Most runs — the OOB read lands in other valid kernel buffer-cache mappings (kernel_map is densely populated around the buffer hash). The CRC then almost certainly mismatches → the node is flagged HAMMER_NODE_CRCBAD → the mount (or lookup) returns EIO. No kernel message is printed at the default hammer_debug_critical level. No userspace-observable info leak.
• Some runs — if the OOB read happens to cross an unmapped KVA page, the kernel takes a protection fault in hammer_datacrc → panic. This is a deterministic DoS for that specific image, but it is mount-time only (so the threat is "the admin who mounts a malicious image loses the box"), not a remote or unprivileged-user DoS.

There is no escalation path from this primitive: it is a pure read, the bytes never leave the kernel, and the only feedback channel to userspace is a 1-bit CRC oracle that requires thousands of crafted-mount attempts to leak even one byte of adjacent kernel memory. This matches the Low severity rating in the finding.

What the fix changes

fix.diff adds a bounds check in hammer_load_node() right after the offset is masked, returning EIO (consistent with the existing CRC-bad path) when the masked offset would not leave room for a full hammer_node_ondisk (4096 bytes) inside the 16384-byte buffer:

if ((node->node_offset & HAMMER_BUFMASK) >
    HAMMER_BUFSIZE - sizeof(struct hammer_node_ondisk)) {
    error = EIO;
    goto failed;
}

DF-0798 — Verdict

Verdict: REPRODUCED + FIX VALIDATED

Status: reproduced Impact: panic (DoS via crafted HAMMER filesystem image mount; OOB kernel heap read in B-Tree CRC validation) Severity: Low (matches finding) Confidence: certain

Mechanism (confirmed by source trace + live panic)

A crafted HAMMER filesystem image supplies a vol0_btree_root whose low 14 bits (offset & HAMMER_BUFMASK, range 0..16383) exceed HAMMER_BUFSIZE - sizeof(struct hammer_node_ondisk) = 16384 − 4096 = 12288. The kernel never validates this offset before using it.

The trigger path is the very first B-Tree lookup of any HAMMER mount:

1. mount_hammer → hammer_vfs_mount (sys/vfs/hammer/hammer_vfsops.c) → hammer_vfs_root (line 743) → hammer_vfs_vget → hammer_get_inode → hammer_init_cursor (sys/vfs/hammer/hammer_cursor.c:160).
2. hammer_init_cursor calls hammer_get_node(trans, volume->ondisk->vol0_btree_root, 0, &error). hammer_get_node asserts only the zone bits via hammer_is_zone_btree() (sys/vfs/hammer/hammer_ondisk.c:1214); it never checks the in-buffer offset.
3. hammer_load_node (sys/vfs/hammer/hammer_ondisk.c:1306) computes: c node->ondisk = (void *)((char *)buffer->ondisk + (node->node_offset & HAMMER_BUFMASK)); With offset & 0x3FFF = 0x3FFC, node->ondisk points 4 bytes before the END of the 16384-byte buffer.
4. hammer_load_node immediately calls hammer_crc_test_btree() (line 1315), which at sys/vfs/hammer/hammer_crc.h:227 does: c hammer_datacrc(vol_version, &node->crc + 1, HAMMER_BTREE_CRCSIZE); HAMMER_BTREE_CRCSIZE is sizeof(struct hammer_node_ondisk) - sizeof(hammer_crc_t) = 4096 − 4 = 4092 (sys/vfs/hammer/hammer_btree.h:247). So the CRC engine reads 4092 bytes starting at node->ondisk + 4 = buffer->ondisk + 0x4000 — i.e. 4092 bytes ENTIRELY PAST the 16384-byte buffer.

Live reproduction (unpatched #0 kernel)

The PoC (run.sh) creates a valid 4 GB HAMMER image with newfs_hammer, mounts it briefly RW to allocate the root B-Tree node, unmounts, patches vol0_btree_root's low 14 bits to 0x3FFC (via patch_btree_root.c), then mounts the patched image read-only. The mount panics deterministically:

Fatal trap 12: page fault while in kernel mode
cpuid = 1; lapic id = 1
fault virtual address   = 0xfffff8005bd1a000     <-- KVA past the buffer's mapping
fault code      = supervisor read data, page not present
instruction pointer = 0x8:0xffffffff809d4e34
kernel: type 12 trap, code=0
Stopped at      calculate_crc32c+0x84:  movzbl  -0x1(%rcx),%r9d

calculate_crc32c is hammer_datacrc. The fault address differs across runs (0xfffff800761ba000, 0xfffff8005434a000, 0xfffff8005bd1a000) — i.e. the OOB read lands in whatever KVA happens to be mapped past the buffer. When it crosses into an unmapped page, the kernel takes a page fault and panics. The signature matches the cited line exactly.

Reproduced 3× on the default X86_64_GENERIC kernel (INVARIANTS ON, 6.5-DEVELOPMENT #0), each run panicking at calculate_crc32c+0x84.

Realistic impact ceiling (no escalation)

This is a pure read. The bytes are never copied to userspace — the CRC engine just computes a checksum and compares it to node->crc. The only feedback to the attacker is a 1-bit "CRC matched / did not match" oracle (and on this guest, almost always a panic from crossing an unmapped page). Realistic outcomes:

• Most common (deterministic on this guest): panic at calculate_crc32c when the OOB read crosses an unmapped page. Mount-time DoS only (the admin who mounts the crafted image loses the box). NOT reachable by an unprivileged user without vfs.usermount=1 plus a root-created, attacker-owned vnode/image.
• If adjacent KVA happens to be mapped: silent OOB read into adjacent buffer-cache memory; CRC mismatches; mount fails with EIO; no kernel message at default hammer_debug_critical. No info leak to userspace.
• Theoretical CRC side-channel: single-bit oracle, ~1024 crafted-mount attempts per byte leaked. Practically useless.

No escalation path exists. There is no write, no control-flow hijack, no attacker-controlled pointer overwrite. This is a textbook Low-severity mount-time DoS / latent info-leak ceiling. The finding's severity rating is correct.

Exploit chain

none — non-write primitive. The bug is a bounded OOB kernel heap read in filesystem image parsing; there is no path from this primitive to privilege escalation. The chain stops at "panic on mount of crafted image" (DoS).

PoC changes

The finding was filed without a PoC evidence pack. I built the entire pack from scratch:

• patch_btree_root.c — small C helper that reads the current vol0_btree_root (8-byte LE at struct offset 240 in the on-disk volume header) and ORs its low 14 bits with 0x3FFC, keeping the high bits (zone/volume/buffer-selector) intact so the blockmap lookup still succeeds and points to the legitimate root buffer.
• run.sh — orchestrates image creation (newfs_hammer -f), RW mount + populate + unmount, byte-patch, RO mount of the crafted image. Run as root (mounting any filesystem requires it; this matches the threat model of an admin mounting a malicious image).
• build.sh — compiles the helper with cc -O -o patch_btree_root patch_btree_root.c.

The mask 0x3FFC was chosen for 4-byte alignment of node->crc while still exceeding the safe maximum (12288), so the entire 4092-byte CRC validation read happens past the buffer end.

Fix

fix.diff adds a single hunk in hammer_vfs_mount (just before hammer_flusher_create, which is before any B-Tree access). The hunk validates rootvol->ondisk->vol0_btree_root against both the zone encoding and the in-buffer bounds; if malformed it prints HAMMER: malformed vol0_btree_root <offset> and returns EINVAL, so the mount fails cleanly without ever reaching the OOB read.

This is a more user-visible placement than the literal line cited in the finding (hammer_ondisk.c:1306): the cited line is the right root-cause location, but fixing it there in isolation is insufficient because hammer_init_cursor and many of its callers (hammer_inode.c:499 etc.) discard the error return and would still crash later in btree_search with a NULL cursor->node->ondisk. Validating the offset at mount time — the single entry point that actually unconditionally fails the mount — closes the bug end-to-end without touching any caller.

The fix was validated by building a single-fix #1 kernel and re-running the identical PoC: the patched kernel prints HAMMER: malformed vol0_btree_root 8000000021003ffc, the mount returns EINVAL (mount: Invalid argument), the guest stays up, and there is no panic in boot.log. Reproduced 3× deterministically.

(An alternative in-place clamp at hammer_ondisk.c:1306 was also tried and correctly closes the OOB read, but routes the failure through the existing CRCBAD/EIO path that the callers don't all handle — exposing pre-existing latent KKASSERT/NULL-deref issues in hammer_init_cursor and hammer_inode.c:499. The mount-time validation sidesteps those entirely and is the recommended minimal fix.)

Recommended fix

findings/poc/DF-0798/fix.diff — superset of the finding's ## Recommended fix proposal: same bounds expression (> HAMMER_BUFSIZE - sizeof(hammer_node_ondisk) → EIO) the finding suggested, but applied at the mount entry point (hammer_vfsops.c:738) instead of in hammer_load_node, so the rejection propagates cleanly through the existing goto done path rather than tripping unrelated caller bugs.