DF-2618 — Overlapping key ranges in on-disk blockref arrays unvalidated — chain-insert collision panic / rbtree root wipe

• Verified 2026-08-28 by df-bsd-reviewer (verify mode) on the QEMU/KVM DragonFly guest, stock INVARIANTS kernel #0 (Thu Jul 2 06:02:54 2026) and fix-validated on rebuilt kernel #1. *

What the finding claims

hammer2_chain_cmp() (sys/vfs/hammer2/hammer2_chain.c:97-118) treats overlapping [key, key + 2^keybits - 1] ranges as a match (cmp == 0). A crafted on-disk parent whose blockref array contains two overlapping brefs drives RB_INSERT in hammer2_chain_insert() (chain.c:313-320) into a collision: INVARIANTS builds panic at the KASSERT (chain.c:314); release builds continue with a phantom chain (ONRBTREE set but never linked) whose later RB_REMOVE wipes parent->core.rbtree's root (sys/sys/tree.h:641-652).

Result

REPRODUCED (panic), then FIXED.

• Baseline (stock INVARIANTS kernel): mounting the forged image and stating a file whose inum-keyed lookup crosses the overlapping entries panics deterministically:

  panic: hammer2_chain_insert: collision 0xfffff80118c22100 0xfffff80118c21980 (key=0000000000000401)

  hammer2_chain_insert() at hammer2_chain_insert+0x15b hammer2_chain_get() at hammer2_chain_get+0x64 hammer2_chain_lookup() at hammer2_chain_lookup+0x615 hammer2_chain_inode_find() at hammer2_chain_inode_find+0x117 hammer2_xop_nresolve() at hammer2_xop_nresolve+0x1a5

(panic.txt, serial capture; guest down.) The trigger is pure namei/readdir activity on a mounted image — no special privileges beyond the mount itself.

• Release-build consequence (rbtree root wipe): verified by line-precise source trace — see VERDICT.md §3. Not demoed on a no-INVARIANTS kernel (build cost); the trace is exact and the INVARIANTS panic proves the primitive.

• Fix validation (fix.diff, rebuilt kernel #1): the same crafted image mounts, ls lists every dirent, lookups that cross the corrupt entries fail with ENOENT instead of panicking, the fix's rate-limited hammer2_chain_insert: collision ... (key=0000000000000401) message appears exactly once on the console, a write to the corrupt directory succeeds, umount is clean, and the system (which roots on hammer2) stays up. Control image: 100% normal behavior on both kernels.

Reproduce

Host side (from this directory):

./build.sh     # mkbase2618.sh in guest -> base2618.img; forge -> craft2618.img; push
./run.sh       # control run (no panic), then craft run (panic on stock kernel)

Guest side:

sh /root/poc/df2618/trigger.sh control   # pristine image: everything works
sh /root/poc/df2618/trigger.sh craft     # forged image: panic at `stat c`
                                        # (serial: vm.sh log; see panic.txt)

For fix validation: apply fix.diff in the guest /usr/src, make -j6 nativekernel && make installkernel, reboot, rerun both triggers (fix_control_run.log / fix_run.log / fix_write_smoke.log).

The forged image

forge_df2618.py walks volhdr -> sroot -> PFS "testvol" inode -> indirect array and patches two file-INODE brefs so their key ranges overlap:

INODE(a) key=1024 keybits 0->1   => [1024,1025]   (swallows 1025)
INODE(b) key=1025 keybits 0->1   => [1025,1026]   (extends beyond)

Sorted array order is preserved (only keybits changed). CHECK_NONE (methods=0x00) is set on the covering indirect bref, the PFS inode bref and the sroot bref, and all volhdr CRC32Cs are recomputed (technique proven in DF-2616/DF-2617/DF-2620).

Trigger mechanics (see VERDICT.md for the full trace): stat a pins chain(1024)=[1024,1025] in the indirect chain's core.rbtree via the inode cache; stat c -> hammer2_chain_inode_find(1026) -> base_find skips [1024,1025] (its end < 1026) and stops at the overlapping [1025,1026] bref; hammer2_chain_find misses (pinned chain ends at 1025); chain_get -> RB_INSERT -> cmp == 0 -> KASSERT panic.

DF-2618 VERDICT — verified reproduced (panic) on stock INVARIANTS kernel; fix validated on rebuilt kernel

Guest: DragonFly dfbsd 6.5-DEVELOPMENT #0 x86_64 (stock, INVARIANTS), dfbsd-qemu/vm.sh. Baseline panic captured 2026-08-28 ~19:44 UTC; fix validated 19:52-19:58 UTC on rebuilt kernel #1.

1. Reproduction (baseline, stock kernel #0)

Crafted image craft2618.img (forge details in README.md):

root@dfbsd# mount -t hammer2 /dev/vn0@testvol /mnt/h2   # OK
root@dfbsd# ls /mnt/h2                                   # a b c d  (OK)
root@dfbsd# stat /mnt/h2/a                               # OK (inum 1024)
root@dfbsd# stat /mnt/h2/c
panic: hammer2_chain_insert: collision 0xfffff80118c22100 0xfffff80118c21980 (key=0000000000000401)

Full serial capture in panic.txt; guest went down (vm.sh status => down). The panic is 100% deterministic across the two runs performed (run.log stops mid-script at the same stat; panic2.txt = second capture during re-test of the identical image — identical signature).

Why it fires (line-precise)

1. forge_df2618.py sets INODE(1024).keybits=1 => [1024,1025] and INODE(1025).keybits=1 => [1025,1026] in the indirect array at media offset 0x1c01000 (array order by key preserved: 1024 < 1025 < 1026 < 1027).
2. stat a (nresolve) -> hammer2_chain_inode_find(1024) (chain.c:5640) -> hammer2_chain_lookup [1024,1024] -> base_find (chain.c:4921) stops at INODE(1024) -> hammer2_chain_get (chain.c:2051) -> hammer2_chain_insert (chain.c:292) inserts chain(1024)=[1024,1025] into the indirect parent's core.rbtree. The inode (ip) keeps the chain referenced (pinned) after the stat.
3. stat c -> hammer2_chain_inode_find(1026) -> lookup [1026,1026]: - base_find: INODE(1024).end=1025 < 1026 -> advance; INODE(1025).end= 1026 >= 1026 -> break at the overlapping entry (chain.c:4975-4986). - hammer2_chain_find (chain.c:1931, RB_SCAN of the rbtree): pinned chain(1024) covers [1024,1025], not 1026 -> no match. - combined_find (chain.c:5020): only the blockref matched -> hammer2_chain_get on INODE(1025) (chain.c:2613).
4. hammer2_chain_insert -> RB_INSERT (chain.c:313) walks to pinned chain(1024): hammer2_chain_cmp (chain.c:97-118): c1=[1024,1025] (new chain), c2=[1024,1025] (existing) -> overlap -> returns 0 -> RB_INSERT returns the existing node (sys/sys/tree.h:674-675) -> KASSERT(xchain == NULL) (chain.c:314) -> panic, exactly the finding's claim.

Impact on the stock kernel: local kernel panic (DoS) from mounting and stat'ing files on a corrupt/crafted hammer2 volume. Precondition: the mount itself (root, or unprivileged with vfs.usermount=1 + accessible device) — matching the Medium severity and hammer2 bucket of the filed finding.

2. Control (stock kernel #0 and fixed kernel #1)

Pristine base2618.img: mount, ls, all stats, open, read-back — all succeed on both kernels (control.log, fix_control_run.log). The forge — not the base image or the CHECK_NONE edits — is what triggers the bug.

3. Release-build consequence (rbtree root wipe) — source trace

Not demoed on a no-INVARIANTS kernel (extra ~35-min build for an effect that is fully determined by the code); traced line-by-line instead:

• Chains are allocated M_ZERO (chain.c:203-204), so a fresh chain's rbnode (rbe_left/rbe_right/rbe_parent/rbe_color) is all-zero.
• On collision RB_INSERT returns without linking or RB_SET-ting the new element (tree.h:674-675 returns tmp; RB_SET at tree.h:677 is never reached), so the phantom chain's rbnode stays all-NULL.
• Release build compiles out the KASSERT; chain.c:317-319 then sets HAMMER2_CHAIN_ONRBTREE, chain->parent = parent, and bumps parent->core.chain_count for a chain that is not in the tree.
• hammer2_chain_get returns the phantom as a normal chain (error==0; the bcmp at chain.c:2634 passes since bref was copied from the same bref).
• When its last ref drops, hammer2_chain_lastdrop (chain.c:618-628) sees ONRBTREE set and calls RB_REMOVE(&parent->core.rbtree, chain) (chain.c:623). In name##_RB_REMOVE (tree.h:585): RB_LEFT(elm)==NULL -> child = RB_RIGHT(elm) = NULL (tree.h:597-598); parent = RB_PARENT(elm) = NULL (tree.h:641); color = RB_COLOR(elm) = RB_BLACK(0) -> parent==NULL branch executes RB_ROOT(head) = child = NULL (tree.h:651-652), wiping the parent's live rbtree root even though it contains other referenced chains. RB_REMOVE_COLOR(head, NULL, NULL) (tree.h:654-655) is a no-op (loop condition tree.h:510-511 false).
• Consequences: every chain still linked in that tree becomes unreachable by lookup (they keep their refs/locks; chain_count is left inflated), later lookups re-create chains for the same brefs into the now-empty tree, and the orphaned chains can never be found for deletion/flush -> permanent chain leak + lookup misses, and duplicated in-memory state for the same media bref — structural memory corruption of the chain topology, exactly as the finding describes. (Also note tree.h:641-652 runs with the parent core spinlock held, so at least the wipe itself is not racy.)

So the finding's release-path claim is code-confirmed; only the KASSERT panic is directly observable on this guest's INVARIANTS kernel.

4. Fix validation (fix.diff, kernel #1 built 19:52:28 UTC 2026)

fix.diff (git-apply-able, verified with git apply --check against the read-only sys/ tree; applied inside the guest's /usr/src copy):

1. hammer2_chain_insert (chain.c:313-320): on RB_INSERT collision, rate-limited krateprintf + error = HAMMER2_ERROR_CHECK, no ONRBTREE/parent/chain_count/generation mutation (removes the KASSERT and the phantom-state bug in one stroke).
2. hammer2_chain_get (chain.c:2089-2101): EAGAIN keeps the existing unlock/drop/NULL race path; corruption (CHECK) returns the chain locked with chain->error set so callers can skip the entry.
3. hammer2_chain_lookup (chain.c:2616) and hammer2_chain_scan (chain.c:2985): on such an errored unlinked chain, unlock/drop and resume the scan at bref->key + (1 << bref->keybits) — the same advance the DELETED-skip path uses — so iteration can never spin on the bad entry.
4. Flush-time chain_get sites (create_indirect chain.c:3942, indirect maintenance chain.c:4195): skip past the corrupt bref (key advanced), keeping those loops finite.
5. hammer2_chain_create (chain.c:3325): insert failure marks chain->error (chain destroyed cleanly on drop since ONRBTREE is unset).

Rebuild: cd /usr/src && make -j6 nativekernel && make installkernel (fix_build.log, BUILD_RC=0, 38176 lines untrimmed), reboot into #1.

Rerun of the exact same PoC:

• trigger.sh control (pristine): identical-to-stock behavior, all operations succeed (fix_control_run.log).
• trigger.sh craft (forged): mount OK, ls lists a b c d, stat a OK, stat b/stat c fail ENOENT (graceful: the overlapping entries shadow keys 1025/1026 — pre-fix the same lookups either ENOENT'd (b) or PANICKED (c)), script completes, guest stays up (fix_run.log).
• Console shows the fix's detection message exactly once: hammer2_chain_insert: collision 0xfffff80118d82880 0xfffff80118d82100 (key=0000000000000401) (dmesg.txt).
• Write smoke test on the corrupt image: create/read/sync/umount of /mnt/h2/newfile all succeed; system (hammer2 root) stable (fix_write_smoke.log).

fix_status: fixed — baseline behavior (deterministic panic) gone, no regression on the control image, sane degradation on the corrupt image.

5. Notes / limitations

• The panic needs only VOP lookup activity; the explicit fd-pin originally planned for the trigger turned out unnecessary (the inode cache alone pins the colliding chain across the two stats).
• The release-build root-wipe was verified by trace, not runtime (see §3); building a no-INVARIANTS kernel was out of time budget and would not change the classification (the INVARIANTS panic proves the overlap primitive; the trace proves the release consequence).
• not-a-bug check: hammer2_chain_cmp's overlap==match semantics are intentional (comment chain.c:104-107) and load-bearing for hammer2_chain_find; the defect is the absence of corruption handling when the on-disk array violates the no-overlap invariant, which the fix adds at the single choke point all media-driven inserts pass through.