DF-2617 — PoC evidence pack

hammer2_chain_load_data() (sys/vfs/hammer2/hammer2_chain.c:938-939) treats bref.data_off == 0 as an early SUCCESS return for every blockref type, so data-requiring types (INODE, INDIRECT, DATA, media DIRENT, FREEMAP_*) end up with chain->data == NULL and chain->error == 0. Every consumer that trusts the (absent) error then dereferences NULL or wedges forever in the debugging loop at chain.c:2524-2529.

Verified sinks (all from mount/ls of a crafted image, root):

Reproduce

# guest (root): build the base image (newfs_hammer2 -L testvol + 33 files)
sh mkbase2617.sh                                   # -> base2617.img

# host: forge the three malformed images
python3 forge_df2617.py base2617.img P1 P1.img     # sroot data_off = 0
python3 forge_df2617.py base2617.img P2 P2.img     # PFS inode data_off = 0
python3 forge_df2617.py base2617.img H  H.img      # INDIRECT data_off = 0
# (push images + trigger_*.sh to guest:/root/poc/df2617/)

# guest (root), stock kernel:
sh trigger_P1.sh    # expect Fatal trap 12 in hammer2_vfs_mount  (panic.txt)
sh trigger_P2.sh    # expect Fatal trap 12 in hammer2_pfsalloc   (panic2.txt)
sh trigger_H.sh     # expect MOUNT_RC=0, then unkillable ls + kthread wchan 'xxx'

Success criteria (stock INVARIANTS kernel #0, uname in env.txt): * P1/P2: Fatal trap 12: page fault while in kernel mode on the serial console with the addresses above. * H: hammer2: unexpected NULL data on <chain> on console; ls process remains in D5/h2coll after kill -9; a h2xop-* kernel thread sits on wchan xxx forever; the mount is unusable.

With fix.diff applied (kernel #1) all three triggers fail cleanly (kprintf + EINVAL mount failure / EIO readdir, no panic, no hang) and the uncorrupted base image still mounts and lists normally (fix_run.log).

• Full narrative: VERDICT.md
• Machine verdict: verdict.json (schema: audit/persist_poc.py)
• Verified fix: fix.diff (git-apply-able; validated by guest rebuild)

Forger technique (from DF-2616/DF-2620): CHECK_NONE (methods=0x00) every ancestor bref whose media block contains edited bytes, recompute the three volume-header CRC32Cs of every on-disk volhdr copy.

DF-2617 VERDICT — zero data_off silent NULL in hammer2_chain_load_data

Status: REPRODUCED (panic x2 + unkillable hang) · Impact: dos (kernel NULL dereference panic from mount; permanent unkillable wedge from ls) · Fix: validated on guest (kernel #1 v3) — all three triggers fail cleanly, legit filesystem still mounts and lists.

Root cause (source trace)

hammer2_chain_load_data() (sys/vfs/hammer2/hammer2_chain.c:920) short-circuits when the blockref has no media offset:

938:    if ((chain->bref.data_off & ~HAMMER2_OFF_MASK_RADIX) == 0)
939:        return;

For blockref types that REQUIRE a media data block — INODE, INDIRECT, DATA, media DIRENT (>64-byte names), FREEMAP_NODE, FREEMAP_LEAF — this leaves chain->data == NULL and chain->error == 0. hammer2_chain_lock() returns 0 (chain.c:881), so every chain->error guard downstream of a lock/lookup is disarmed. (Contrast hammer2_chain_alloc() chain.c:185-192, which computes chain->bytes = 0 for radix 0 and documents the embedded case — the only legitimate radix-0 users are embedded dirents, whose names live in the bref itself (hammer2_chain_dirent_test() chain.c:5786-5795 reads bref.check.buf for names <= 64 bytes), and freshly allocated (HAMMER2_CHAIN_INITIAL) chains whose data_off is 0 until hammer2_chain_modify() allocates.)

Sinks verified on the guest (stock INVARIANTS kernel #0)

The finding's cited sink chain.c:2496 (parent->data->ipdata.meta.op_flags for INODE lookup parents) is the same deref family as sinks 1/2 — in the mount flows it is shadowed by the vfsops derefs (which run first), and it is reached generically whenever a corrupt INODE is a lookup parent (e.g. a corrupted subdirectory). Both chain.c:2496 and 2524 are protected by the fix because hammer2_chain_lookup() checks parent->error at chain.c:2473 before the blockref-array switch at 2482 — once load_data arms the error.

PoC

forge_df2617.py (host, python3) builds three malformed images from base2617.img (guest mkbase2617.sh: newfs_hammer2 -L testvol, 33 files, sync, umount — forces INDIRECTs in the PFS root blockset):

• P1 volhdr sroot INODE bref data_off = 0
• P2 PFS "testvol" INODE bref data_off = 0 (CHECK_NONE the sroot bref)
• H first INDIRECT bref under the PFS root data_off = 0 (CHECK_NONE sroot + PFS inode brefs)

Ancestor CHECK_NONE (methods=0x00) + volume-header CRC32C recompute per DF-2616/DF-2620 technique; only volhdr copy #0 carries the magic in these images (the forger patches every copy that does).

Threat model: mount of a crafted hammer2 image — root, or unprivileged with vfs.usermount=1 and an owned device (per the finding).

Fix (fix.diff — 3 hunks, validated by in-guest rebuild)

1. hammer2_chain.c load_data: in the zero-data_off early return, set chain->error = HAMMER2_ERROR_EIO + kprintf for every type except embedded DIRENT and CHAIN_INITIAL chains. This arms every downstream chain->error / parent->error guard (chain.c:2473, vfsops.c:1285/1427/1555).
2. hammer2_vfsops.c:1390 label scan: skip errored chains instead of strcmp()-ing chain->data->ipdata.filename (caught as Fatal trap 12 at VA 0x100, strcmp+0x10, during fix-validation iteration v2).
3. hammer2_iocom.c:313 hammer2_update_spans: skip errored chains instead of reading ripdata->meta.pfs_clid (caught as Fatal trap 12 at VA 0x90, hammer2_autodmsg+0x273 on the iocom thread, during fix-validation iteration v2).

Coordination with DF-2616: orthogonal, not subsuming. DF-2616's hammer2_bad_data_off() treats (data_off & ~MASK_RADIX) == 0 as the legal "embedded, no media block" case and returns 0; DF-2617 covers exactly that case for data-requiring types. Both hunks can coexist: DF-2616 rejects bad geometry when an offset IS present, DF-2617 rejects the absent offset for types that require one.

Residual (documented, not fixed here): other chain->data->ipdata consumers reachable only from other operation paths (e.g. xops.c:403/539 on unlink, vfsops.c:2251 recovery scan) still deref without checking chain->error — with hunk 1 they now fail only if individually guarded; upstream should sweep all ->data-> derefs of lookup results for error checks.

Fix validation (guest, kernel #1 v3, uname in env.txt)

Honest classification notes

• The panic and the hang both require mounting a crafted image. On the stock guest vfs.usermount=0, so root is needed; the finding's threat model (vfs.usermount=1 + owned device) applies unchanged.
• Sink 3 is a permanent, unkillable kernel-side wedge: the sleeping xop thread holds the chain topology lock, so every subsequent operation on the mount piles up; the mount can never be unmounted; the only recovery is a reboot. That is a full local DoS of the machine's storage subsystem, not just of one directory.
• Sink 1/2 are read-only NULL derefs at fixed near-NULL VAs (0x90/0x87) — not directly exploitable for code execution on this kernel config (no way to map page 0), hence DoS classification, matching the finding's Medium severity.

Fix status (batch validation)

Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.