DF-2605 — hammer2 hammer2_chain_alloc unvalidated radix → panic / DoS

Reproduction + fix-validation pack for DF-2605 (sys/vfs/hammer2/hammer2_chain.c:189-190). Same unvalidated-radix root-cause class as the DF-2583 sibling, located at the upstream allocation site.

Reproduce

# in the guest, as the unprivileged user maxx (build only):
cd poc/DF-2605 && sh build.sh

# as root: create a base hammer2 image with an INDIRECT block
sh poc/DF-2605/setup_image.sh

# as root: forge radix=17 on the image, mount, readdir as maxx -> PANIC on #0
sh poc/DF-2605/run.sh 17

Expected (bug present, unpatched #0 GENERIC)

The su maxx ./poc /mnt/h2test/testdir step triggers panic: assertion "pbase != 0 && ((lbase + lsize - 1) & pmask) == pbase" failed in hammer2_io_alloc at /usr/src/sys/vfs/hammer2/hammer2_io.c:126 — guest drops to db>, ssh dies. (radix=32 takes the UB path: gcc evaluates 1U<<32→1, so bytes is bogus; readdir returns EDOM, no panic, but the chain is mis-sized — the UB the finding flags.)

Expected (fixed #1 kernel)

getdents returns errno=33 (EDOM); no panic; guest stays up; dmesg shows hammer2_chain_alloc: ...: forged radix=17 (max=16); capping and marking chain errored. A clean (unforged) image still readdirs normally.

Files

Build / run commands (exact)

• build: cc -O2 -o forge forge.c && cc -O2 -o poc poc.c
• run (as root, after setup_image.sh): sh run.sh 17

DF-2605 — hammer2 hammer2_chain_alloc unvalidated on-disk radix → kernel panic / OOB (DoS on default GENERIC; OOB-write primitive on noinv)

Verdict: REPRODUCED (panic / DoS on default GENERIC; write-primitive characterised on noinv), FIX VALIDATED

The bug is real and confirmed. hammer2_chain_alloc() at sys/vfs/hammer2/hammer2_chain.c:189-190 derives chain->bytes from the low 6 bits of bref->data_off (the "radix") with no range check:

if ((int)(bref->data_off & HAMMER2_OFF_MASK_RADIX))
    bytes = 1U << (int)(bref->data_off & HAMMER2_OFF_MASK_RADIX);
else
    bytes = 0;

A malicious hammer2 filesystem image can set that radix to any of 0..63. HAMMER2_RADIX_MAX is 16 (HAMMER2_PBUFSIZE = 64 KB) but is never enforced at this derivation site. Two failure classes:

1. radix 17..31 — bytes is well-defined (128 KB..2 GB) but exceeds HAMMER2_PBUFSIZE. The unprivileged readdir path drives the kernel into hammer2_io_alloc() (hammer2_io.c:126) where the KKASSERT(pbase != 0 && ((lbase + lsize - 1) & pmask) == pbase) trips because the oversized request crosses a 64 KB page. Panic on default GENERIC (INVARIANTS ON) — reproduced.

2. radix >= 32 — 1U << radix is undefined behaviour (shift count >= type width). On gcc 8.3 x86-64 -O2 the shl masks the count to 5 bits, so e.g. 1U << 32 evaluates to 1, producing a bogus bytes and a mis-sized 1-byte I/O. Confirmed: no panic, but chain->bytes is wrong (implementation-defined) — exactly the latent UB the finding flags.

On a non-INVARIANTS kernel the hammer2_io.c:126 KKASSERT is skipped and the oversized chain->bytes later drives the OOB blockref-array walk in hammer2_flush_core() (hammer2_flush.c:1094, count = parent->bytes / sizeof(hammer2_blockref_t)) — the same write-capable primitive characterised in the DF-2583 sibling (same root-cause class). On the default GENERIC kernel that primitive is masked by the earlier KKASSERT and manifests purely as a DoS panic; per the bright-line rule this is reported as panic on GENERIC (the realistic target), with the noinv OOB-write noted as a non-default-kernel characterisation.

The fix is validated on a built-and-booted single-fix kernel (#1): the same forged image (radix 17 — which panicked the baseline #0) now mounts and readdir returns EDOM (errno 33) instead of panicking; the guest stays up; the warnonce kprintf from the new alloc-site guard fires. radix 32 (UB path) is also cleanly rejected. A clean (unforged) image still readdirs all 13 files — no regression.

Mechanism (trigger → primitive → effect)

1. Attacker input. A hammer2 image has an INDIRECT blockref whose bref.data_off low 6 bits are forged to 17 (data_off = 0x1c01011). The full hammer2 CRC chain (XXH64 over inode/indirect blocks with seed 0x4d617474446c6c6e, CRC32C over the volume header) is recomputed by forge.c so the kernel accepts the forged blockref.

2. Unvalidated derivation at hammer2_chain.c:189-190 (the DF-2605 root cause): bytes = 1U << 17 = 131072, no bound check. HAMMER2_RADIX_MAX (= 16) is defined in hammer2_disk.h:89 but never enforced here.

3. Reachable from unprivileged readdir. getdents(2) on the directory whose inode blockset holds the forged INDIRECT bref descends: hammer2_chain_get → hammer2_chain_lock → hammer2_chain_load_data (hammer2_chain.c:940) → hammer2_io_bread(data_off, bytes=131072) → _hammer2_io_getblk → hammer2_io_alloc.

4. Default GENERIC (INVARIANTS ON): the KKASSERT at hammer2_io.c:126 fails (lsize=131072 > HAMMER2_PBUFSIZE=65536 crosses a page boundary). Illegal: 0000000001c00000 0000000001c01000+00020000 / ffffffffffff0000 then panic: assertion ... failed in hammer2_io_alloc. Guest → db>, ssh dies. Reproduced (see panic.txt).

5. radix >= 32 (UB): 1U << radix is UB; on this gcc bytes wraps to a tiny value, so the I/O KKASSERT does not fire, but the chain is mis-sized and readdir returns EDOM. The behaviour is implementation-defined — a different compiler/flags could produce anything (including a huge bytes that does panic). The finding's UB concern is real.

6. noinv (non-default): KKASSERT skipped → the oversized parent->bytes drives count = parent->bytes / 128 at hammer2_flush.c:1094, iterating the blockref array (base[]) far past its actual size → OOB read/write of kernel heap with attacker-influenced blockref data on sync. This is the DF-2583 write primitive (same root cause). Not escalated to uid=0 here: on the realistic target (default GENERIC) the KKASSERT converts this to a pure DoS panic before any OOB write lands, which is the valid hard blocker for a default-kernel escalation.

Exploit chain / impact

• Impact class: memory-corruption-primitive (oversized/UB radix → oversized chain->bytes) surfaced as a DoS panic on the default GENERIC kernel.
• Bucket / victim object: N/A for the default-kernel demonstration — the KKASSERT at hammer2_io.c:126 fires before any heap victim is touched. The write primitive (noinv only) targets the INDIRECT block's npdata[] blockref array at hammer2_flush.c:1094; characterised in DF-2583.
• Unprivileged reachability: yes — maxx (uid 1001, not in wheel) reads the mounted directory; the forged INDIRECT chain is loaded during getdents. Realistic precondition: an admin mounts (or makes mountable via vfs.usermount) a hammer2 image and lets the user read it.
• Why not uid=0: on the default GENERIC kernel (INVARIANTS ON — the realistic target) the hammer2_io.c:126 KKASSERT catches the oversized I/O before any OOB write can land, so the manifestation is a DoS panic, not an escalation. The write-capable OOB only exists on the non-default noinv kernel (characterised in DF-2583; per the bright-line rule a noinv-only escalation is not a default-GENERIC uid0). This is a valid hard blocker (the primitive is masked by INVARIANTS on the default kernel).

The fix (validated)

fix.diff makes two minimal, targeted changes in sys/vfs/hammer2/hammer2_chain.c:

1. hammer2_chain_alloc (root cause, DF-2605): compute radix once; if radix > HAMMER2_RADIX_MAX, do not execute the UB/oversized 1U << radix — instead cap bytes = 1U << HAMMER2_RADIX_MAX and mark the chain HAMMER2_ERROR_CHECK (with a warnonce kprintf). This closes both the radix-17..31 oversized-I/O path and the radix>=32 UB at the derivation site.

2. hammer2_chain_load_data (companion, = the DF-2583 guard): reject a chain already marked errored (or with bytes > HAMMER2_PBUFSIZE) before calling hammer2_io_bread(). This is what actually prevents the I/O-layer KKASSERT: the errored chain short-circuits, callers return EDOM/EIO, no panic.

The pair fully closes DF-2605 (and subsumes DF-2583's downstream guard).

Before / after (decisive)

PoC changes

Authored from scratch (the finding shipped no PoC). Reused the CRC-chain forger pattern proven on the DF-2583 sibling (XXH64 seed 0x4d617474446c6c6e, CRC32C volume header) — DF-2605 is the same unvalidated-radix root-cause class, re-targeted at the upstream hammer2_chain_alloc site. Files: forge.c (image forger), poc.c (getdents trigger), setup_image.sh (creates a base hammer2 image with enough entries to force an INDIRECT block), build.sh / run.sh, fix.diff, full logs.