DF-0772 — Infinite loop in hammer2_fixup_pfses on non-INODE blockref

Summary

hammer2_fixup_pfses() in sys/vfs/hammer2/hammer2_vfsops.c enters an infinite loop when it encounters a non-INODE blockref under the super-root inode during a read-write mount. The loop body checks chain->bref.type != HAMMER2_BREF_TYPE_INODE and executes continue, bypassing the hammer2_chain_next() advance at the bottom of the loop. Since chain is unchanged, the loop re-evaluates the identical type check and continues forever — a tight kernel busy-loop.

The spin holds the global hammer2_mntlk lockmgr lock and the spmp->iroot inode lock, blocking all subsequent HAMMER2 mount/unmount operations system-wide (including root-FS sync). Impact: denial of service triggered by mounting a crafted HAMMER2 filesystem image read-write (root-mount threat model, CVSS PR:H).

The bug (line-by-line)

// sys/vfs/hammer2/hammer2_vfsops.c:2389-2417  (VULNERABLE)
while (chain) {
    if (chain->bref.type != HAMMER2_BREF_TYPE_INODE)
        continue;                    // <-- BUG: chain NOT advanced
    if (chain->error) {
        ...
    } else if (...) {
        ...
    }
    chain = hammer2_chain_next(...); // <-- NEVER REACHED for non-INODE
}

The sibling function hammer2_update_pmps() (same file, lines 1553-1566) shows the correct pattern: the type check is inside an if/else-if chain so hammer2_chain_next() at the bottom is always executed.

Trigger

1. Create a valid HAMMER2 image: dd if=/dev/zero ... && newfs_hammer2.
2. Corrupt one child blockref of the super-root inode: change its type byte from INODE (1) to DATA (3) (or any non-INODE, non-EMPTY value), and set the super-root blockref's check method to CHECK_NONE so the modified inode data passes CRC validation during volume-header loading.
3. vnconfig -c vn0 image.img && mount_hammer2 /dev/vn0 /mnt/x (RW).
4. The mount syscall enters hammer2_vfs_mount → hammer2_fixup_pfses, hits the non-INODE child, and spins forever.

Fix

Restructure the type check into an if/else-if chain (mirroring hammer2_update_pmps) so hammer2_chain_next() is always reached. See fix.diff.

Files

Reproduce

# On the DragonFlyBSD guest as root:
dd if=/dev/zero of=/tmp/h2.img bs=1m count=512
newfs_hammer2 /tmp/h2.img
cc -o /tmp/corrupt_h2 corrupt_h2.c /usr/src/sys/libkern/icrc32.c
/tmp/corrupt_h2 /tmp/h2.img corrupt    # flip child[0] type INODE→DATA
vnconfig -c vn0 /tmp/h2.img
mkdir -p /mnt/h2test
mount_hammer2 /dev/vn0 /mnt/h2test     # RW mount → HANGS on unpatched kernel

DF-0772 — VERDICT

Verdict: REPRODUCED — system-wide HAMMER2 DoS via infinite loop

Status: reproduced (DoS / infinite loop) Impact: dos — kernel busy-loop holding global hammer2_mntlk, blocking all HAMMER2 mount/unmount/sync Confidence: certain Fix status: fixed — validated on single-fix kernel

Mechanism

hammer2_fixup_pfses() (sys/vfs/hammer2/hammer2_vfsops.c:2366-2425) is called during a read-write HAMMER2 mount (after hammer2_recovery() succeeds) to fix mis-flagged PFS inodes. It scans the super-root inode's children:

// VULNERABLE (lines 2389-2417)
chain = hammer2_chain_lookup(&parent, &key_next, KEY_MIN, KEY_MAX, &error, 0);
while (chain) {
    if (chain->bref.type != HAMMER2_BREF_TYPE_INODE)
        continue;                    // BUG: chain is NOT advanced
    if (chain->error) { ... }
    else if (...) { ... }
    chain = hammer2_chain_next(&parent, chain, &key_next, ...);  // SKIPPED
}

When chain->bref.type != HAMMER2_BREF_TYPE_INODE (e.g., a crafted image has a DATA type=3 blockref as a child of the super-root), continue jumps back to while (chain) without calling hammer2_chain_next(). Since chain is unchanged, the loop re-evaluates the same type check → continue → spin forever.

Why the loop holds the system hostage

• hammer2_vfs_mount() acquires the global hammer2_mntlk lockmgr lock early (line ~1056, held through line ~1486). The infinite loop is inside this critical section.
• hammer2_inode_lock(spmp->iroot, 0) is held (line 2384 → 2423).
• ALL subsequent HAMMER2 mount/unmount operations block on hammer2_mntlk. The root filesystem is on HAMMER2 (vbd0s1d on / (hammer2)), so sync/unmount of the root FS is also blocked.

Correct sibling: hammer2_update_pmps (lines 1553-1566)

while (chain) {
    if (chain->error) { ... }
    else if (chain->bref.type != HAMMER2_BREF_TYPE_INODE) {
        kprintf("Non inode chain type %d under super-root\n", ...);
    } else { ... }
    chain = hammer2_chain_next(...);  // ALWAYS reached
}

The fix restructures hammer2_fixup_pfses to match this pattern.

Reachability analysis

1. hammer2_vfs_mount (line ~1056): acquires hammer2_mntlk.
2. Volume header loaded and CRC-validated (hammer2_ondisk.c:485-560). Our corruption tool recomputes the 3 volume-header CRCs (iscsi_crc32) so this passes.
3. Super-root inode loaded via hammer2_chain_lookup on hmp->vchain (line ~1273). Our tool sets the blockref check method to CHECK_NONE so the modified inode data passes CRC.
4. hammer2_recovery(hmp) returns 0 ("no recovery needed" — confirmed in serial log).
5. hammer2_fixup_pfses(hmp) enters the infinite loop.

The trigger requires a crafted HAMMER2 image mounted RW by root (!hmp->ronly gate at line 1334). RO mounts skip the vulnerable path.

Reproduction evidence

Baseline (unpatched #0 kernel)

Serial log (serial_log_baseline.txt) after RW mount of corrupted image:

hammer2_mount: device="/dev/vn0" label="DATA" rdonly=0
hammer2_ondisk: "/dev/vn0" zone=0 id=0 offset=0x0 size=0x20000000
hammer2_mount: "/dev/vn0": no recovery needed
[SILENCE — kernel spinning in hammer2_fixup_pfses]

• ssh uptime times out (guest unresponsive, all CPUs eventually starved by the spinning thread holding mntlk).
• Load average on an earlier run: 1.59 (one CPU fully consumed).
• A second HAMMER2 mount (clean image) also blocks on hammer2_mntlk.

Patched (#1 kernel, fix applied)

Serial log (serial_log_patched.txt) after RW mount of the SAME corrupted image:

hammer2_mount: device="/dev/vn0" label="DATA" rdonly=0
hammer2_mount: "/dev/vn0": no recovery needed
hammer2: Non-inode chain type 3 under super-root, skipping   ← FIX FIRED
Non inode chain type 3 under super-root                       ← hammer2_update_pmps
HAMMER2: VOLDATA DUMP
HAMMER2: INITIATE SPANs                                       ← mount PROCEEDED PAST fixup

• Load average: 0.01 (CPU NOT spinning — no infinite loop).
• ssh responsive; echo, uptime, mount all return immediately.

The before/after contrast is unambiguous: the infinite loop is eliminated.

The corruption tool (corrupt_h2.c)

A userspace C tool that: 1. Reads the volume header (first 64KB of the image). 2. Follows sroot_blockset.blockref[0].data_off to the super-root inode data. 3. Changes the first child blockref's type byte from INODE(1) to DATA(3). 4. Sets the super-root blockref's check method to CHECK_NONE (so the modified inode data isn't rejected by the CRC check during chain loading). 5. Recomputes the 3 volume-header CRCs (iscsi_crc32 from kernel libkern).

Compiled with: cc -o corrupt_h2 corrupt_h2.c /usr/src/sys/libkern/icrc32.c

Fix validation

fix.diff

Restructures the if (... != INODE) continue; + if (chain->error) into an if (... != INODE) { kprintf(...); } else if (chain->error) chain, so hammer2_chain_next() at the bottom of the loop is always reached. Adds a diagnostic kprintf matching hammer2_update_pmps's style.

Build + install

• make -j6 quickkernel KERNCONF=X86_64_GENERIC → rc=0 (warm obj, ~90s).
• make installkernel + copy kernel.stripped → /boot/kernel/kernel.
• Booted: DragonFly 6.5-DEVELOPMENT #1: Thu Jul 9 20:29:43 UTC 2026.

Before/after

Conclusion: fix closes the bug. The infinite loop in hammer2_fixup_pfses is eliminated; the mount proceeds past the fixup function on the patched kernel.

Notes

• The mount may still be slow on the patched kernel for reasons unrelated to this bug (HAMMER2 cluster/iocom messaging setup on a vn-backed image with no cluster peers). This is a separate behavior, not the infinite loop.
• The trigger requires root to mount (PR:H). A real-world scenario: an admin mounts a malicious HAMMER2 image (e.g., from an untrusted USB device or a downloaded filesystem image).
• RO mounts are unaffected (gated by !hmp->ronly).