DF-2662 — hammer2_update_spans() dereferences chain->data of an EIO-failed inode chain (NULL deref panic)

• File: sys/vfs/hammer2/hammer2_iocom.c (found during the pass-2 audit of sys/vfs/hammer2/hammer2_io.c — unmasked while validating DF-2661's fix)
• Severity: Medium (kernel NULL-deref panic; triggered by device read errors)
• Bucket: hammer2

Build

Kernel B (baseline for THIS bug) = stock + DF-2661 fix (fix_b.diff) + DF-2661/inject.diff. With the DF-2661 assert fixed, the same trigger exposes this bug in isolation.

Kernel C (fix validation) = kernel B source + fix.diff (this pack).

cd /usr/src
patch -p1 < /root/df2661/inject.diff
patch -p1 < /root/df2661/fix_b.diff
patch -p1 < /root/df2662/fix.diff
make -j6 nativekernel KERNCONF=X86_64_GENERIC && make installkernel ...

Run

sh /root/df2661/trigger_df2661.sh golden   # once
sh /root/df2661/trigger_df2661.sh 5        # ARM=1 default

Expected

Kernel B: Fatal trap 12: page fault ... Stopped at hammer2_autodmsg+0x273: movq 0x90(%r15),%rax — r15 == 0 is chain->data == NULL for a PFS inode whose read failed with EIO during the post-mount async SPAN walk (hammer2_update_spans).

Kernel C: 5x ROUND_SURVIVED + ALL_ROUNDS_SURVIVED.

DF-2662 VERDICT — hammer2_update_spans() NULL deref on EIO-failed inode chain

Status: REPRODUCED (panic, kernel B) / FIXED (kernel C)

The bug

hammer2_update_spans() (sys/vfs/hammer2/hammer2_iocom.c:285) walks the super-root's PFS entries asynchronously after every mount — it is invoked from hammer2_autodmsg()'s "VOLDATA DUMP" branch (iocom.c:237) when the auto-CONN handshake reply arrives.

The walk does:

chain = hammer2_chain_lookup(&parent, &key_next, ...);
while (chain) {
    if (chain->bref.type != HAMMER2_BREF_TYPE_INODE)
        continue;
    ripdata = &chain->data->ipdata;      /* <-- no error check */

hammer2_chain_lookup() returns INODE chains even when hammer2_chain_load_data() failed: the chain comes back locked with chain->error = HAMMER2_ERROR_EIO and chain->data == NULL (hammer2_chain.c:996-1001 prints the "I/O error" line and leaves data NULL). update_spans never checks either and dereferences chain->data->ipdata -> NULL+offset reads (meta.pfs_clid at +0x90).

Secondary latent bug in the same loop: the bare continue for non-INODE chains never advances the iteration (hammer2_chain_next is only called at the loop tail) -> infinite kernel loop should the super-root ever contain a non-INODE entry. The fix advances before continuing.

Reproduction (kernel B = stock + DF-2661 fix + EIO injector)

Same trigger as DF-2661 (512MB vn-backed hammer2 volume, injector armed, concurrent cold inode loads). With DF-2661's assert fixed, the box no longer dies in the DIO layer; instead the post-mount async SPAN walk hits the injected EIO on a PFS inode (data_off 0x240040a) and:

Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x90
instruction pointer = 0x8:0xffffffff80967933
Stopped at hammer2_autodmsg+0x273: movq 0x90(%r15),%rax

Disassembly (disasm_autodmsg.txt) pins the faulting load to the ripdata->meta.pfs_clid/pfs_fsid/pfs_type/filename copy into the freshly allocated LNK_SPAN message (offsets 0x90/0x98/0xa0/0x100 exactly match struct hammer2_inode_data). See panic.txt for the full transcript.

This crash was observed WHILE the DF-2661 fix was active — i.e. it is an independent, pre-existing EIO-path bug (previously masked on stock kernels by DF-2661's earlier panic in the same workload).

Fix validation (kernel C = kernel B + fix.diff)

fix.diff skips chains whose data failed to load and advances the iteration for skipped entries:

if (chain->bref.type != HAMMER2_BREF_TYPE_INODE ||
    chain->data == NULL) {
    chain = hammer2_chain_next(...);
    continue;
}

Kernel C survived the identical 5-round EIO storm (ROUND_SURVIVED x5), see fix_run.log. (Same run also re-validates DF-2661's fix end-to-end.)

Threat model

Same environmental class as DF-2661: any device read error hitting a super-root PFS inode during the asynchronous post-mount SPAN walk panics the kernel. Timing-wise this one is even easier to hit than DF-2661 — no concurrency is required, the async walk alone suffices if the PFS inode read fails. Impact: local DoS. No memory disclosure (pure NULL deref), no privilege boundary. Severity: Medium.

Kernel references

• sys/vfs/hammer2/hammer2_iocom.c:285-325 (update_spans walk, missing chain->error/chain->data check; bare-continue infinite loop)
• sys/vfs/hammer2/hammer2_iocom.c:237 (async invocation from autodmsg)
• sys/vfs/hammer2/hammer2_chain.c:985-1006 (lookup returns chain with data == NULL and error == EIO)