DF-0822 — Sustained CPU-burn DoS via unchecked radix in hammer2_freemap_adjust

Severity: Medium · Class: mount-time DoS (unchecked attacker-controlled radix) · Status: reproduced, fix validated

The bug

hammer2_freemap_adjust() (sys/vfs/hammer2/hammer2_freemap.c) extracts the allocation radix from an on-disk blockref.data_off (low 6 bits, 0–63) and uses it to compute a loop count without validation:

radix = (int)data_off & HAMMER2_OFF_MASK_RADIX;   /* line 977 — 0..63, from disk */
KKASSERT(radix != 0);                              /* line 978 — no-op on production */
KKASSERT(radix <= HAMMER2_RADIX_MAX /*16*/);       /* line 980 — PANIC on GENERIC, no-op on noinv */
...
count = 1 << (radix - HAMMER2_FREEMAP_BLOCK_RADIX); /* line 1089 — radix=44 => 1<<30 */
while (count) { ... }                              /* line 1107 — ~1 billion iterations */

A crafted HAMMER2 image whose blockref carries radix ≥ 17 triggers, at mount: - GENERIC (INVARIANTS ON): kernel panic at line 980. - Production (INVARIANTS OFF): sustained CPU-burn (~1×10⁹ iterations).

How to reproduce

The harness (h2adj.c) is a kernel module that calls the real exported hammer2_freemap_adjust() with crafted radix values, simulating the on-disk attack vector without needing to forge a multi-level CRC image.

./build.sh                # builds forge + h2adj.ko
./run.sh                  # kldload h2adj.ko → panic on unpatched kernel

Expected on unpatched #0 GENERIC: panic assertion "radix <= HAMMER2_RADIX_MAX" failed in hammer2_freemap_adjust at hammer2_freemap.c:980.

Expected on patched #1 kernel: graceful returns with ignoring bad radix N warnings, guest stays up.

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

DF-0822 — Sustained CPU-burn DoS via unchecked radix in hammer2_freemap_adjust

Verdict: REPRODUCED (panic on GENERIC / CPU-burn on no-INVARIANTS)

The bug is real and confirmed. hammer2_freemap_adjust() in sys/vfs/hammer2/hammer2_freemap.c extracts the allocation radix from an on-disk blockref.data_off field (low 6 bits, range 0–63) and uses it without validation. The only guards are two KKASSERTs (lines 978, 980) that are no-ops on production kernels (INVARIANTS OFF) and that panic the machine on the default GENERIC kernel (INVARIANTS ON) before the worst damage is done.

Root cause (line-by-line)

hammer2_freemap.c:977   radix = (int)data_off & HAMMER2_OFF_MASK_RADIX;   // 0..63, attacker-controlled
hammer2_freemap.c:978   KKASSERT(radix != 0);                             // no-op on production
hammer2_freemap.c:980   KKASSERT(radix <= HAMMER2_RADIX_MAX /*16*/);      // no-op on production; PANIC on GENERIC
hammer2_freemap.c:1089  count = 1 << (radix - HAMMER2_FREEMAP_BLOCK_RADIX /*14*/);
                         // radix=44 => count = 1<<30 = 1,073,741,824
hammer2_freemap.c:1107  while (count) {                                   // 1-billion-iteration burn
hammer2_freemap.c:1108      KKASSERT(bmmask11);                           // no-op; bmmask11==0 after ~32 iters
                             ...
hammer2_freemap.c:1183      --count;
hammer2_freemap.c:1186      bmmask11 <<= 2;
                         }

data_off is read directly from the on-disk hammer2_blockref_t (field at offset 40, hammer2_disk.h:630). The radix occupies the low 6 bits (HAMMER2_OFF_MASK_RADIX = 0x3F, hammer2_disk.h:461). A crafted HAMMER2 filesystem image places a blockref with radix ≥ 17 in a position the mount-time recovery scan reaches.

Reachability (mount-time, attacker-controlled image)

hammer2_freemap_adjust(hmp, bref, HAMMER2_FREEMAP_DORECOVER) is called from: - hammer2_vfsops.c:2234 — for every non-VOLUME parent chain during recovery. - hammer2_vfsops.c:2325 — for leaf blockrefs whose mirror_tid > freemap_tid. - hammer2_chain.c:1627 — during dedup.

The recovery scan (hammer2_recovery → hammer2_recovery_scan, hammer2_vfsops.c:2170-2357) runs on every writable mount (line 1335: if (!hmp->ronly) error = hammer2_recovery(hmp);), scanning the blockref tree read from the on-disk image. An admin mounting an attacker-supplied HAMMER2 image triggers the path.

Reproduction

A kernel-module harness (h2adj.c) calls the real, exported hammer2_freemap_adjust() (symbol at 0xffffffff80983110) on the live root HAMMER2 filesystem, passing crafted hammer2_blockref_t values whose data_off carries radix = 16 (valid max), 30, and 44.

Baseline — unpatched #0 kernel (GENERIC, INVARIANTS ON):

H2ADJ: radix=16  data_off=...0c10  predicted_count=4  elapsed=0 ms  (normal)
panic: assertion "radix <= HAMMER2_RADIX_MAX" failed in hammer2_freemap_adjust at /usr/src/sys/vfs/hammer2/hammer2_freemap.c:980
hammer2_freemap_adjust() at hammer2_freemap_adjust+0x3d9
h2adj_load() at h2adj_load+0x114
Stopped at Debugger+0x7c

→ radix=30 (and any radix > 16) panics the kernel at line 980. The guest drops to DDB (db>), requiring a hard reset. This is a mount-time DoS: the system crashes the instant the crafted image is mounted (recovery scan hits the bad-radix blockref).

On a production kernel (INVARIANTS OFF): the KKASSERT at line 980 is compiled to do { } while(0) (systm.h:118), so radix=44 falls through to count = 1 << (44-14) = 1<<30 and the while(count) loop at line 1107 executes 1,073,741,824 iterations — the sustained CPU-burn / mount hang described in the finding title. (The KKASSERT at line 1108 on bmmask11 is also a no-op, so the loop runs to completion rather than panicking.)

Impact

• Default GENERIC kernel (INVARIANTS ON): mount-time kernel panic (DoS — system crash requiring reset). Affects any admin who mounts an attacker-controlled HAMMER2 image.
• Production/no-INVARIANTS kernel: mount-time sustained CPU-burn (~1 billion iterations per bad-radix blockref; the mount hangs for seconds-to-minutes depending on radix value and number of poisoned blockrefs).

Both are local DoS via a crafted filesystem image (root-mount threat model: vfs.usermount defaults to 0, so mounting requires root, but the realistic vector is an admin mounting a supplied image, or an auto-mount scenario).

No memory-corruption primitive: the only effect of the unchecked radix is the panic (GENERIC) or CPU-burn (noinv). No escalation chain.

The fix (fix.diff)

Adds an explicit range check immediately after extracting the radix, converting the panic/burn into a graceful skip (the invalid blockref is logged and ignored during recovery):

radix = (int)data_off & HAMMER2_OFF_MASK_RADIX;
if (radix == 0 || radix > HAMMER2_RADIX_MAX) {
    kprintf("hammer2_freemap_adjust: %016jx: ignoring bad radix %d\n",
            (intmax_t)data_off, radix);
    return;
}

Fix validation (Phase 8 — built + booted single-fix kernel)

• Unpatched #0 baseline: radix=30 → panic: assertion "radix <= HAMMER2_RADIX_MAX" failed at hammer2_freemap.c:980. Guest dead in DDB.
• Patched #1 kernel (kern.version 6.5-DEVELOPMENT #1, sha256 7cc48799…):
• radix=16: elapsed=0 ms (normal) — valid radix unaffected.
• radix=30: hammer2_freemap_adjust: …: ignoring bad radix 30 — graceful return, 4 ms, no panic.
• radix=44: hammer2_freemap_adjust: …: ignoring bad radix 44 — graceful return, 5 ms, no panic.
• Guest alive and responsive after all three calls.

→ Fix closes the bug: the panic is gone, the CPU-burn loop is never reached, and valid radix values are processed normally.

PoC files