DF-0804 — Panic / NULL deref via crafted HAMMER2 image in strategy_read_completion

Severity: Medium Class: CWE-754 (Improper Check for Exceptional Conditions) / DoS File: sys/vfs/hammer2/hammer2_strategy.c:441-502 CVSS: 3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Verdict

REPRODUCED on the default GENERIC kernel (6.5-DEVELOPMENT #0), then FIX-VALIDATED on a single-fix #1 kernel. Impact: panic / DoS (kernel halt from a crafted filesystem image). No privilege escalation — this is a pure denial-of-service at a fixed code offset.

The bug

hammer2_strategy_read_completion() is the read-strategy completion callback for HAMMER2. It dispatches on focus->bref.type and, for DATA blocks, on the compression nibble of focus->bref.methods. Both dispatch tables terminate in unconditional panic() instead of returning EIO:

• hammer2_strategy.c:496 — panic("unknown compression type") for any HAMMER2_DEC_COMP(methods) value other than NONE(0)/LZ4(2)/ZLIB(3). HAMMER2_COMP_AUTOZERO (1) and crafted values 4–15 reach here.
• hammer2_strategy.c:500 — panic("unknown bref type") for any bref.type other than INODE(1)/DATA(3).

Additionally the INODE branch at :452 does an unconditional bcopy from data; if bref.data_off == 0, hammer2_chain_load_data() (hammer2_chain.c:938) returns early leaving chain->data == NULL and chain->error == 0, so the NULL pointer reaches bcopy → page fault.

The type/methods/data_off fields are loaded verbatim from media by hammer2_chain_lookup() / hammer2_chain_get() (hammer2_chain.c:2599) with no value-range validation — a crafted image controls them freely.

Threat model

Filesystem-image parsing: an unprivileged actor can supply a HAMMER2 image (USB media, downloaded image, multi-tenant storage). When an admin (or an automated mount) mounts it and a file is read, the kernel panics. This is a local denial-of-service with no privilege boundary to cross beyond "image is mountable."

Reproduction (live image, full CRC re-weave)

The non-trivial part is that HAMMER2 verifies per-blockref check codes (XXH64) and the volume header's iSCSI-CRC32 trio. A naive byte-flip of the methods field fails the parent inode's CRC and the mount rejects the image. The trigger therefore:

1. newfs_hammer2 a fresh image, write one 64 KiB file (forces a DATA bref).
2. Flip the DATA bref methods low nibble: NONE(0) → 4 (undefined).
3. Walk the check cascade and recompute every covering digest so the image still passes integrity verification: * file-inode XXH64 → BOOT-inode bref .check * BOOT-inode XXH64 → SUPROOT-inode bref .check * SUPROOT-inode XXH64 → volume-header sroot bref .check * volume-header ICRC1 (sroot sector) → icrc_sects[6] * volume-header ICRC0 (sector 0) → icrc_sects[7] * volume-header ICRCVH (whole 64 KiB) → icrc_volheader
4. mount_hammer2 + cat target.bin → on the unpatched kernel: panic: hammer2_strategy_read_completion: unknown compression type.

The re-weave is implemented in pure Python (corrupt_image.py) — XXH64 (validated against the reference xxhash package for ≥32-byte payloads) and CRC32C/Castagnoli (validated against the 0xE3069283 test vector).

Files

Quick reproduce

On a DragonFlyBSD master DEV guest with hammer2 in the kernel:

python3 corrupt_image.py h2.img <file_off> <boot_off> <suproot_off>
vnconfig -c -S labels -T vn1 h2.img
mount_hammer2 /dev/vn1@BOOT /mnt
cat /mnt/target.bin > /dev/null      # panics on unpatched, EIO on fixed

(offsets come from hammer2 show /dev/vn1 | grep inode.0.)

DF-0804 — VERDICT

Verdict: REPRODUCED on default GENERIC #0; FIX-VALIDATED on single-fix #1. Impact: panic / DoS (local, via crafted HAMMER2 image). No escalation path (NULL deref / panic at a fixed offset — pure availability impact).

Mechanism (trigger → primitive → effect)

1. Trigger. A crafted HAMMER2 image is mounted and a file is read. The image's DATA blockref for that file carries bref.methods with low nibble 4 (undefined compression). The blockref passes integrity verification because the attacker (who controls the whole image) recomputes the covering XXH64/CRC32 cascade — see corrupt_image.py.

2. Primitive. The read reaches hammer2_strategy_read_completion() (sys/vfs/hammer2/hammer2_strategy.c:441). The DATA branch (:458 → :474) does switch (HAMMER2_DEC_COMP(focus->bref.methods)). The value 4 matches none of NONE/LZ4/ZLIB and falls through to the default: at :495:

c default: panic("hammer2_strategy_read_completion: " "unknown compression type");

3. Effect. panic() → Debugger("panic") → all CPUs stopped, DDB prompt, system halted. Serial console:

panic: hammer2_strategy_read_completion: unknown compression type hammer2_xop_strategy_read() at hammer2_xop_strategy_read+0x606 Stopped at Debugger+0x7c: movb $0,0xbdaf09(%rip) db>

The same function has a second unconditional panic("unknown bref type") at :500 for any bref.type other than INODE(1)/DATA(3), and a latent NULL deref in the INODE branch (:452) when bref.data_off == 0 (which makes hammer2_chain_load_data return early at hammer2_chain.c:938 leaving chain->data == NULL, chain->error == 0).

Why no escalation

This is a panic() / NULL-deref at a fixed code offset with no attacker-controlled write primitive. The crash terminates the kernel; there is no corrupted object to groom, no function pointer to redirect. It is a pure denial-of-service. (The guest has SMAP/SMEP/KASLR off, but those only matter for a write/control primitive — a panic is game-over-by-definition with no shell to land.)

Reachability confirmation (line-by-line)

• hammer2_xop_strategy_read() (:308) calls hammer2_chain_lookup() (:344) with HAMMER2_LOOKUP_ALWAYS — forces data resolution.
• hammer2_chain_lookup() (:2387) scans the parent's blockref array via hammer2_combined_find() (:2599) which returns the on-disk bref without validating type/methods/data_off ranges.
• hammer2_chain_get() builds a chain copying bsave = *bref verbatim (:2599); hammer2_chain_load_data() (:920) honours data_off and, if (data_off & ~HAMMER2_OFF_MASK_RADIX) == 0, returns at :938 with chain->data still NULL and chain->error still 0.
• Frontend (:401-410): error == 0 → data = hammer2_xop_gdata()->buf → hammer2_strategy_read_completion(focus, data, bio).
• hammer2_strategy_read_completion() :474 switch → :495 default → panic.

Fix (fix.diff)

Three changes, all in hammer2_strategy_read_completion:

1. NULL-data guard in the INODE branch (:452): if data == NULL, set B_ERROR/EIO and return (closes the data_off==0 NULL-deref).
2. HAMMER2_COMP_AUTOZERO case: zero-fill the buffer (comp=1 is a valid "logically zero, not stored" method that previously fell through to panic).
3. Replace both panic() calls (:496, :500) with kprintf + B_ERROR/ EIO + bp->b_resid = bp->b_bcount. A corrupted/crafted image now yields a per-read EIO (and a diagnostic dmesg line) instead of halting the kernel.

Before / after

Reproduced deterministically (×2 on the patched kernel). The build compiled cleanly (make -j6 nativekernel rc=0) and the #1 kernel boots and operates normally.