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.