DF-2643 — hammer2 write xop dereferences the inode chain without the NULL check the read xop performs

sys/vfs/hammer2/hammer2_strategy.c:623-626 — hammer2_xop_strategy_write() passes &parent from hammer2_inode_chain() straight into hammer2_write_file_core() with no NULL check, while the read xop guards the identical call (:340-364). If the inode's cluster chain is gone when the write xop thread runs, the first dereference of the NULL parent is parent->bref.type inside hammer2_chain_lookup() (hammer2_chain.c:2426-2429, reached from strategy.c:734 via hammer2_assign_physical) — NULL-deref panic in a kernel xop thread, plus a stuck bio.

Verified on the QEMU guest

DragonFly 6.5-DEVELOPMENT, INVARIANTS kernels rebuilt in-guest from the guest's /usr/src (md5-identical to the audited tree):

• K2 = stock code + harness.diff (sysctl vfs.hammer2.df2643_harness that releases the freshly-acquired chain and forces parent = NULL right after hammer2_inode_chain() in hammer2_xop_strategy_write — i.e. the exact post-race state the hammer2_admin.c:556-563 XXX comment admits is possible)
• K3 = stock code + harness + fix.diff (the NULL guard)

Demonstrated

Reachability (honest)

hammer2_inode_chain() returns NULL only when the inode's cluster slot for clindex is empty or nchains shrank. A strategy xop is only queued to a thread whose cluster slot was non-NULL at xop_start time (hammer2_admin.c:556-563, whose XXX comment explicitly admits the array is not stable and races can NULL-out chains). So the panic needs the slot to transition to NULL between queue and run: device removal / cluster repoint / PFS teardown racing an in-flight write — root-triggered admin operations (multi-device or replication topologies; this snapshot has no runtime volume-del, so no natural single-device trigger exists). The mechanical deref-and-panic is proven by the harness; the natural race window is speculative. Severity Low stands.

Fix (validated)

fix.diff adds the same guard the read xop has: if parent == NULL, skip hammer2_write_file_core(), error = HAMMER2_ERROR_EIO, feed it, and let the existing frontend completion fail the bio with EIO (:675-681). fix.diff applies cleanly on stock; K3 (harness+fix) A/B validated above.

Reproduce

Build harness kernel in guest /usr/src:

patch -p0 < harness.diff            # K2 (panic demo)
make -j6 nativekernel KERNCONF=X86_64_GENERIC && make installkernel
shutdown -r now
./run_panic_test.sh                 # panics into db> (capture serial)

then rebuild with the guard:

patch -p0 < fix.diff                 # K3
make -j6 nativekernel KERNCONF=X86_64_GENERIC && make installkernel
shutdown -r now
./runfix_test.sh                     # A/B/C: EIO, no panic, guest alive

Files

harness.diff          K2 sysctl knob (DF2643 HARNESS ONLY, not upstream)
fix.diff              the upstream NULL guard (git-apply-able)
run_panic_test.sh     K2 trigger (write + sync -> panic)
runfix_test.sh        K3 A/B/C validation script
panic.txt             Fatal trap 12 @ hammer2_chain_lookup+0x92 (K2)
runfix.knob-on.log    K3 knob-on console tail (error 1 spam, 0 traps)
k3build.log           K3 full build log (BUILD_RC=0)
k3install.log         K3 install log
env.txt VERDICT.md manifest.json verdict.json

DF-2643 VERDICT — REPRODUCED (mechanically, via sanctioned harness); reachability remains the admin-op race; fix validated

The claim, made line-accurate

hammer2_xop_strategy_write() (sys/vfs/hammer2/hammer2_strategy.c:577-686) acquires the per-clindex parent chain at :623

parent = hammer2_inode_chain(ip, clindex, HAMMER2_RESOLVE_ALWAYS);

and immediately passes &parent into hammer2_write_file_core() (:624-626) with no NULL check. The read xop performs the identical acquisition at :340 and explicitly handles NULL at :351-354:

} else {
    error = HAMMER2_ERROR_EIO;
    chain = NULL;
}

hammer2_inode_chain() (hammer2_inode.c:408-428) returns NULL when clindex >= cluster->nchains or the cluster slot is empty.

Where the NULL first dereferences (refinement of the finding)

The finding cites strategy.c:760 ((*parentp)->hmp inside hammer2_assign_physical) as the first deref. In fact every write-path variant reaches hammer2_chain_lookup(parentp, ...) BEFORE that:

• COMP_NONE: write_file_core :847 -> assign_physical :734 chain_lookup
• AUTOZERO/non-zero: zero_check_and_write :1223 -> assign_physical :734
• zero block: zero_write :1278 chain_lookup
• LZ4/ZLIB: compress_and_write :1061 -> assign_physical :734

and hammer2_chain_lookup() derefs the parent immediately at hammer2_chain.c:2426-2429:

parent = *parentp;
*errorp = 0;
while (parent->bref.type == HAMMER2_BREF_TYPE_INDIRECT || ...

bref sits at offset 0x98 in hammer2_chain on this kernel — which is exactly where the machine faulted (below). strategy.c:760 would be the next deref (only reachable if the lookup tolerated NULL, which it does not).

Reproduction (K2 = stock code + harness knob)

Because this snapshot has no runtime device-removal path (only hammer2 volume-list exists in sbin/hammer2; no volume-add/del), the natural trigger (cluster slot NULLing between xop queue and run — the exact race hammer2_admin.c:556-563 XXX admits: "does not address possible races against inode updates which might NULL-out a chain") cannot be staged naturally on the single-device guest. Per the task directive, a harness kernel was built: harness.diff adds vfs.hammer2.df2643_harness, which — only when enabled — releases the chain hammer2_inode_chain() just acquired (unlock+drop, so nothing leaks) and sets parent = NULL before hammer2_write_file_core(). This is precisely the post-race state.

Kernel #2 (uname ... #2: Tue Oct 20 03:34:11 UTC 2026), STOCK write path:

# sysctl vfs.hammer2.df2643_harness=1
# dd if=/dev/zero of=/mnt/zdir/zfile bs=64k count=1   (buffered, OK)
# sync

-> serial console (panic.txt):

Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x98
fault code = supervisor read data, page not present
Stopped at hammer2_chain_lookup+0x92: movzbl 0x98(%rbx),%eax
CPU3 stopping CPUs: 0x00000037
 stopped
db>

• fault VA 0x98 = &parent->bref.type with parent == NULL (rbx = 0).
• faulting frame hammer2_chain_lookup+0x92 = the parent->bref.type loop-head read at hammer2_chain.c:2429 — the exact instruction predicted from source.
• all CPUs stopped; machine dead at DDB; the bio is never completed (stuck-write behavior on a live system).

Fix validation (K3 = stock + harness + fix.diff)

Kernel #3 (uname ... #1: Tue Oct 20 03:49:24 UTC 2026) adds the guard (fix.diff): NULL parent -> skip write_file_core, error = HAMMER2_ERROR_EIO, existing feed/collect/completion path fails the bio with EIO (strategy.c:675-681).

Same forced-NULL operation (knob=1, dd + sync):

• No panic. 0 Fatal trap lines; guest stayed up and answered ssh.
• Every strategy write attempt with the forced-NULL parent logged xop_strategy_write: error 1 loff=0000000000000000 (error 1 = HAMMER2_ERROR_EIO) — 20948 messages because the harness forces EVERY retry of the still-dirty buffer to fail (a real race fails once and the retry succeeds); the livelock is a harness artifact, not fix behavior.
• knob=0 before/after: normal writes succeed — zero behavioral delta for healthy code paths.

Reachability honesty (unchanged from the finding)

• Requires the inode cluster slot for the running xop thread to transition to NULL (or nchains to shrink) between xop queue time and run time: device removal / cluster repoint / PFS teardown racing in-flight writes.
• xop_start only queues threads whose slots were non-NULL at queue time (hammer2_admin.c:556-563 + its XXX comment admitting the instability).
• All such transitions are root-triggered admin operations on multi-device/replication topologies; none exist in this snapshot for a single-device mount. No unprivileged or remote trigger.
• Therefore: mechanical NULL-deref = certain (captured), natural trigger = speculative race (root admin ops). Low severity confirmed. Impact ceiling: kernel NULL-deref panic (DoS) + one stuck bio; no memory-safety primitive (fixed-address read fault at 0x98).

Kernel references

• sys/vfs/hammer2/hammer2_strategy.c:623-626 (unguarded pass-through)
• sys/vfs/hammer2/hammer2_strategy.c:340-364 (the read xop's guard)
• sys/vfs/hammer2/hammer2_strategy.c:734 (assign_physical -> chain_lookup)
• sys/vfs/hammer2/hammer2_strategy.c:760 (later (*parentp)->hmp deref site)
• sys/vfs/hammer2/hammer2_chain.c:2426-2429 (actual first deref, parent->bref.type, offset 0x98 confirmed by trap)
• sys/vfs/hammer2/hammer2_inode.c:408-428 (hammer2_inode_chain NULL return)
• sys/vfs/hammer2/hammer2_admin.c:556-563 (XXX race admission)
• sys/vfs/hammer2/hammer2_strategy.c:675-681 (existing EIO completion the fix routes into)

Bottom line

REPRODUCED via the sanctioned harness on a rebuilt stock-code kernel: the write xop's missing NULL guard turns the admin.c-admitted chain-NULL race into a deterministic NULL-deref panic at hammer2_chain_lookup+0x92 (fault VA 0x98, all CPUs stopped). The one-line guard fix (mirroring the read xop) was A/B validated on the same harness: forced-NULL writes now fail with EIO through the existing error completion, no panic, healthy paths unchanged. Natural trigger remains the root-admin device/repoint race — Low severity stands.

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.