DF-0763 — Missing on-disk radix validation in hammer2 chain allocation

Verdict: REPRODUCED (panic on default GENERIC). Impact: panic / reliable local DoS from a crafted hammer2 filesystem image. On a non-INVARIANTS kernel the same primitive becomes a silent heap OOB read/write (characterized, not escalated on the default target).

See VERDICT.md for the full mechanism and fix.diff for the validated fix.

What the bug is

hammer2_chain_alloc (sys/vfs/hammer2/hammer2_chain.c:189-190) computes chain->bytes = 1U << radix from the low 6 bits of the on-disk bref->data_off without validating radix <= HAMMER2_RADIX_MAX (16). A malicious image setting radix 17..63 makes chain->bytes exceed HAMMER2_PBUFSIZE (64KB), and the subsequent hammer2_io_bread drives hammer2_io_alloc (hammer2_io.c:126) into a KKASSERT panic on INVARIANTS-ON kernels (the default).

How to reproduce

# On the host (has python3):
./build.sh                    # builds vnconfig (guest), creates+crafts the image
ssh -F dfbsd-qemu/config dfbsd 'cp /tmp/h2_craft_radix17.img /tmp/ && sh /root/run_remote.sh'
# or, after build.sh has pushed the image to the guest:
./run.sh                      # mounts the crafted image -> panic on #0, EINVAL on #1

Expected

• Unpatched kernel (#0): immediate kernel panic at hammer2_io.c:126 (KKASSERT: pbase != 0 && ((lbase + lsize - 1) & pmask) == pbase), guest enters DDB, ssh dies. Serial log excerpt in panic.txt.
• Patched kernel (#1): mount returns EINVAL, dmesg shows hammer2_mount: error Bad Blockref Error reading super-root, guest stays up. Clean image still mounts and works (no regression).

Files

Preconditions (realistic)

• Attacker can supply a hammer2 filesystem image that a victim mounts (USB media, downloaded image, vfs.usermount=1 with a user-owned device, auto-mount). No special privilege beyond image delivery is required.
• The vulnerable kernel is the default X86_64_GENERIC (hammer2 compiled in; root fs on this guest is hammer2).

The fix

fix.diff adds: 1. A radix bounds check in hammer2_chain_alloc that flags the chain with HAMMER2_ERROR_BADBREF when radix > HAMMER2_RADIX_MAX. 2. An early-return guard in hammer2_chain_load_data that rejects any chain already flagged HAMMER2_ERROR_BADBREF, preventing the bad radix from reaching hammer2_io_bread/hammer2_io_alloc.

Validated on a single-fix kernel (#1): the panic is gone, the crafted image is cleanly rejected with EINVAL/Bad Blockref Error, and normal hammer2 operation (mount/read/write of a clean image) is unaffected.

DF-0763 — Verdict

REPRODUCED — Missing on-disk radix validation in hammer2 chain allocation. Impact: panic (reliable DoS on default GENERIC with INVARIANTS ON). On a non-INVARIANTS kernel the same primitive becomes a silent heap OOB read/write (characterized below, not escalated on the default target).

The bug, confirmed

hammer2_chain_alloc (sys/vfs/hammer2/hammer2_chain.c:189-190) extracts the on-disk radix from the low 6 bits of bref->data_off and uses it to compute chain->bytes with no bounds check:

189: if ((int)(bref->data_off & HAMMER2_OFF_MASK_RADIX))
190:     bytes = 1U << (int)(bref->data_off & HAMMER2_OFF_MASK_RADIX);

HAMMER2_OFF_MASK_RADIX is 0x3F (hammer2_disk.h:461) — a 6-bit field, so the radix can be 0..63. The valid range is only 0 (no data) and HAMMER2_RADIX_MIN=10 .. HAMMER2_RADIX_MAX=16 (hammer2_disk.h:87,89), i.e. 1KB..64KB. 64KB is HAMMER2_PBUFSIZE (hammer2_disk.h:106), the size of the kernel DIO buffer cache page.

A malicious filesystem image setting radix=17 (or any 17..63) makes bytes = 1<<17 = 128KB. When hammer2_chain_load_data (hammer2_chain.c:920) later calls hammer2_io_bread(... chain->bytes ...), hammer2_io_alloc (hammer2_io.c:115-126) recomputes lsize = 1<<17 = 128KB independently from data_off, then validates:

122: if (pbase == 0 || ((lbase + lsize - 1) & pmask) != pbase) {
123:     kprintf("Illegal: %016jx %016jx+%08x / %016jx\n", ...);
124: }
125: /* falls through to: */
126: KKASSERT(pbase != 0 && ((lbase + lsize - 1) & pmask) == pbase);

Because lsize=128KB spans two 64KB DIO pages, (lbase + lsize - 1) & pmask != pbase — the KKASSERT panics on INVARIANTS-ON kernels (the default X86_64_GENERIC).

The downstream OOB sinks the finding cites are real and reachable on a non-INVARIANTS kernel, but are masked by the io_alloc KKASSERT on default GENERIC: - hammer2_chain.c:1827 bcopy(chain->data, bdata, chain->bytes) — 128KB COW bcopy into a 64KB DIO buffer (OOB read + write). - hammer2_chain.c:5395,5547 XXH64(bdata, chain->bytes, ...) — 128KB hash read from a 64KB buffer (OOB heap read).

Reproduction (live, on the real kernel)

The DragonFly guest's root filesystem is hammer2, so the VFS code is compiled in and fully live. Steps (build.sh automates; run.sh triggers):

1. vnconfig is built from /usr/src/usr.sbin/vnconfig/ (not installed by default; make install adds it).
2. A clean 64MB image is made with newfs_hammer2 -L testvol.
3. craft_radix_img.py patches sroot_blockset[0].data_off (the blockref pointing at the super-root inode) radix bits from 0x0a (10) to 0x11 (17), and recomputes the three volume-header CRCs: - icrc_sects[6] (sector-1 CRC over the sroot_blockset), - icrc_sects[7] (sector-0 CRC, invalidated by changing [6]), - icrc_volheader (whole-header CRC). All CRCs use CRC32C (Castagnoli, iscsi_crc32 in sys/libkern/icrc32.c).
4. vnconfig -c vn0 image && mount -t hammer2 /dev/vn0@testvol /mnt/h2test.

Baseline result (unpatched #0, INVARIANTS ON): the mount panics immediately — the kernel enters DDB, ssh dies, vm.sh status ⇒ down. Serial-log panic signature (panic.txt):

Illegal: 0000000001400000 0000000001400000+00020000 / ffffffffffff0000
panic: assertion "pbase != 0 && ((lbase + lsize - 1) & pmask) == pbase" failed in hammer2_io_alloc at /usr/src/sys/vfs/hammer2/hammer2_io.c:126
_hammer2_io_getblk() at _hammer2_io_getblk+0xc6
_hammer2_io_bread() at _hammer2_io_bread+0x17
hammer2_chain_load_data() at hammer2_chain_load_data+0x2a5
hammer2_chain_lock() at hammer2_chain_lock+0xde
hammer2_chain_get() at hammer2_chain_get+0x45
Stopped at Debugger+0x7c: movb $0,0xbdaf09(%rip)
db>

lsize = 0x20000 (128KB) and pmask = 0xFFFF0000 confirm radix 17 drove the request past the DIO page. Reproduced deterministically on two independent fresh-reset runs.

Impact ceiling & why escalation stops here (GENERIC)

On the default X86_64_GENERIC kernel (INVARIANTS ON) the KKASSERT at hammer2_io.c:126 fires before any OOB access — the primitive never materializes as memory corruption, only as a panic. This is a valid hard blocker for uid=0 escalation on the realistic target: there is no write primitive to groom because INVARIANTS traps the oversized request at the IO gatekeeper before chain->data is even set.

On a hypothetical INVARIANTS-OFF kernel the same radix=17 would proceed silently: the bread() would still return a 64KB DIO buffer, but chain->bytes (128KB) would drive a 64KB over-read in XXH64 (testcheck, hammer2_chain.c:1071/:5395) and — if the chain is subsequently modified — a 64KB over-read+over-write in bcopy(chain->data, bdata, chain->bytes) (hammer2_chain.c:1827). That is a genuine heap OOB read/write primitive in the kmalloc-65536 page-zone that could in principle be groomed for privilege escalation, but only on a non-default kernel. Per the bright-line rule this is reported as panic for the default GENERIC target with the non-default primitive characterized but not escalated.

Realistic threat model: an attacker who can cause a victim to mount (or auto-mount) a crafted hammer2 image achieves immediate kernel panic / DoS on any default DragonFlyBSD configuration. No privilege is required beyond the ability to supply a filesystem image (e.g. a USB stick, a downloaded image, vfs.usermount with a user-owned device). Information disclosure / privilege escalation is theoretically possible but gated on INVARIANTS being off.

The fix (validated)

fix.diff adds a radix bounds check at the first point the on-disk radix is trusted (hammer2_chain_alloc), marking the chain with HAMMER2_ERROR_BADBREF, plus an early-return guard in hammer2_chain_load_data so the bad chain never reaches hammer2_io_bread. hammer2_chain_modify already calls chain_load_data and checks chain->error afterward (hammer2_chain.c:1470-1472), so the bcopy OOB sink is covered too.

Phase 8 validation (single-fix kernel #1, make nativekernel):

No regression on the clean image (mount, read, write, unmount all succeed on #1).

PoC changes from the initial finding scaffolding

The finding folder was empty; everything here was built from scratch: - craft_radix_img.py — host-side image patcher (CRC32C-correct, verified). - build.sh / run.sh — reproducible build & trigger. - h2_clean.img / h2_craft_radix17.img — clean and crafted images. - fix.diff — the validated fix (supersedes the finding's one-liner proposal by adding the chain_load_data guard, which is required because hammer2_io_alloc independently recomputes lsize from data_off). - panic.txt, run.log, fix_run.log, fix_build.log, env.txt.