sub_key-derived bitmap index overflows the 64-bit element in hammer2_bmap_alloc() for non-radix-aligned crafted DATA bref keys — KKASSERT panic (INVARIANTS) / truncated mask with overlapping 64K allocations (noinv)

Summary

hammer2_bmap_alloc()'s DATA fast path (:660-687) derives bitmap indexes i/j from the chain bref's own key (sub_key) with only an after-the-fact KKASSERT that j+bmradix<=64 at :679. The kernel only ever creates radix-16 DATA chains at 64K-aligned keys (hammer2_calc_logical, subr.c:267-281), but a crafted image can supply a DATA bref with a 16K-aligned key (0x7C000): j becomes 62 while bmradix=8 (radix 16), so j+bmradix=70 — KKASSERT panic on INVARIANTS kernels; on production kernels bmmask=(0xFF)<<62 truncates to 2 bits, the 64K allocation marks only one 16K pair, avail -= 64K, and the returned data_off (element base + 62*8K, 64K long) crosses into bitmapq element i+1 whose chunks stay 00 — subsequent allocations overlap this one (DF-2652 class).

Threat model & preconditions

Crafted hammer2 image: a DATA bref {key=0x7C000, keybits=16, radix=16} planted in a file's indirect block (covering a hole) is found by the write path for lbase 0x80000 and COW-modified. Any user of the mounted fs writing into that range triggers the panic/corruption. DoS on default kernels; allocation-overlap corruption on production noinv kernels.

Proof of concept

VERIFIED on the stock guest (findings/poc/DF-2653/): forge_2653.py inserts the poison bref at ascending-key slot 4 of f2653's indirect block (methods=0x30 iscsi32 — 0x00/CHECK_NONE takes the overwrite-in-place path and never reallocates, discovered in iteration 1). Mount, then dd if=<64K urandom> of=/mnt/h2t/f2653 bs=64k seek=8 conv=notrunc → async panic: assertion "j + bmradix <= HAMMER2_BMAP_BITS_PER_ELEMENT" failed in hammer2_bmap_alloc at hammer2_freemap.c:679 with backtrace hammer2_bmap_alloc ← hammer2_freemap_alloc ← hammer2_chain_modify ← hammer2_assign_physical ← hammer2_xop_strategy_write; guest down. Fixed kernel #1: same write completes, readback md5 matches, guest up.

Recommended fix

Turn the assertion into a gate and fall back to the (safe, self-bounded) general element scan:

--- a/sys/vfs/hammer2/hammer2_freemap.c
+++ b/sys/vfs/hammer2/hammer2_freemap.c
@@ -676,7 +676,11 @@
        default:
            break;
        }
-       if (i >= 0) {
+       /*
+        * DF-2653: reject sub_key-derived indexes that do not
+        * leave room for bmradix bits inside the 64-bit element
+        * (crafted DATA bref key that is not radix-aligned gives
+        * j=62 with bmradix=8).  Fall back to the general scan.
+        */
+       if (i >= 0 && j + bmradix <= HAMMER2_BMAP_BITS_PER_ELEMENT) {
            KKASSERT(i < HAMMER2_BMAP_ELEMENTS &&
                 j < 2 * HAMMER2_BMAP_BLOCKS_PER_ELEMENT);
-           KKASSERT(j + bmradix <= HAMMER2_BMAP_BITS_PER_ELEMENT);

References

• DF-2652 (the sibling mask defect in adjust), DF-2616 family

Timeline

• 2026-08-29 Discovered during pass-2 audit of hammer2_freemap.c (GLM 5.3); verified reproduced + fix validated same run.