hammer2_xop_strategy_write dereferences the inode chain without the NULL check the read xop performs — NULL-deref panic if the inode's cluster chain is concurrently gone

Summary

The write xop does parent = hammer2_inode_chain(ip, clindex, HAMMER2_RESOLVE_ALWAYS); (strategy.c:623) and immediately passes &parent into hammer2_write_file_core/hammer2_assign_physical, whose first dereference is hammer2_dedup_lookup((*parentp)->hmp,...) (strategy.c:760) or hammer2_chain_lookup(parentp,...) — a NULL deref/panic. The read xop in the same file checks (if (parent) with an EIO fallback, :340-354). hammer2_inode_chain returns NULL when ip->cluster.array[clindex].chain is NULL (inode.c:408-427), which hammer2_inode_repoint's leftover-chain loop (inode.c:1430-1438) and device-removal paths (vfsops.c:631, 821) can produce; xop_start_except's own XXX admits the race (admin.c:556-563).

Threat model & preconditions

Local DoS (kernel NULL-deref panic) during unmount/device-removal/repoint races on multi-device or error-degraded PFSs; speculative on default single-device mounts. If triggered, the bio is never completed, lwinprog leaks, and the strategy pipe wedges.

Proof of concept

Not verified (Phase V skipped: Low/speculative, no deterministic trigger on the single-device INVARIANTS guest). Recommended trigger study: multi-device PFS with one device failed/removed while dirty buffers flush.

Recommended fix

Mirror the read path: if (parent) { hammer2_write_file_core(...); unlock/drop; } else { error = HAMMER2_ERROR_EIO; } hammer2_xop_feed(&xop->head, NULL, clindex, error); so the write completes with EIO instead of dereferencing NULL.

Timeline

• 2026-08-29 Discovered during pass-2 audit of hammer2_strategy.c (GLM 5.3).