DF-0858 — Unbounded dive depth in hpfs_hpbmap (cyclic AlSec infinite loop)

Bug: hpfs_hpbmap() at sys/vfs/hpfs/hpfs_alsubr.c:78,110 walks the on-disk AlNode/AlSec allocation tree via a dive: label and goto dive with no depth counter, no visited-set, and no cycle detection. A crafted HPFS image with two AlSecs that point at each other (A→B→A) drives the loop into an infinite kernel CPU spin that is unkillable (SIGKILL cannot be delivered while in kernel mode).

Trigger (unprivileged): an admin mounts a crafted HPFS image (realistic precondition); an unprivileged user then does cat /mnt/FILE or even stat /mnt/FILE → VOP_READ/VOP_GETATTR → hpfs_hpbmap → infinite dive. After the first pass both AlSec buffers are B_CACHE, so bread() returns immediately = tight CPU spin.

Impact: DoS — unkillable kernel CPU spin. No corruption → no escalation.

Files

Build

./build.sh        # cc -O2 -Wall -o harness harness.c

Run (deterministic harness — safe)

./run.sh          # ./harness

Expected (BUG PRESENT): harness prints

DF_0858_BUG_CYCLIC_DIVE_LOOPS_FOREVER=1
DF_0858_FIX_DEPTH_CAP_BREAKS_LOOP=1
DF_0858_CONTROL_TERMINATES_NORMALLY=1
DF_0858_BUG_CONFIRMED=1

Run (live — destructive; will hang the guest)

# as root:
mdconfig/vnconfig the image, mount_hpfs -o ro /dev/vnX /mnt
# as unprivileged user:
timeout 10 cat /mnt/FILE &
# watch from a second ssh — top/systat will show one CPU pegged at 100%,
# the cat process is in pfork/wait and CANNOT be killed (kill -9 has no
# effect — it's spinning in kernel mode).  The guest becomes sluggish.
# Recover only with:  ./dfbsd-qemu/vm.sh reset with-src

DF-0858 — VERDICT

Verdict: REPRODUCED (unbounded dive depth / no cycle detection → unkillable kernel CPU spin; root-only mount + unpriv read/stat trigger; no corruption → no escalation; valid hard blocker applies)

Status: reproduced (live kernel hang on the unpatched kernel + deterministic harness + live fix validation) Impact: dos (unkillable kernel CPU spin from a crafted HPFS image; the spinning process cannot be killed because SIGKILL cannot be delivered while in kernel mode — only vm.sh reset recovers) Confidence: certain

Mechanism (root cause, traced path:line)

hpfs_hpbmap() (sys/vfs/hpfs/hpfs_alsubr.c:62) translates a file logical block number bn to a disk offset by walking the on-disk allocation tree of AlNodes (interior) and AlLeaves (extents). The walk is driven by a dive: label and a goto dive with no depth counter, no visited-set, and no cycle detection:

There is no count of how many times dive: is entered. A crafted HPFS image with two AlSecs that point at each other (A→B→A) drives the loop into an infinite dive:

  file fnode.fn_ab (AB_NODES, 1 alnode)  ->  AlSec A
  AlSec A.as_ab (AB_NODES, 1 alnode)     ->  AlSec B
  AlSec B.as_ab (AB_NODES, 1 alnode)     ->  AlSec A   *** CYCLE ***

For any file offset bn (with an_nextoff = 0xFFFFFFFF on every alnode), each iteration: 1. finds the single alnode (bn < 0xFFFFFFFF is always true), 2. brelse()s the previous buffer, 3. bread()s the child AlSec — after the first pass both AlSec buffers are B_CACHE, so bread() returns immediately = tight kernel CPU spin, 4. descends into the child AlBlk and goto dives.

The kernel never returns to userspace, so the process is unkillable (SIGKILL cannot be delivered while in kernel mode) and one CPU pegs at 100 %. The guest becomes unresponsive and only a hard vm.sh reset recovers.

Trigger path (realistic)

vfs.usermount = 0 on this guest, so mounting requires root. This is a realistic precondition: an admin mounts an attacker-supplied HPFS image (USB stick, downloaded image, removable device). Once mounted, the trigger is fully unprivileged:

ls /mnt                # directory readdir — does NOT hit the bug
cat /mnt/FILE          # regular file read → VOP_READ → hpfs_read
                       # → hpfs_hpbmap → infinite dive → CPU peg, unkillable
stat /mnt/FILE         # VOP_GETATTR → hpfs_getattr → hpfs_hpbmap → same

Even a stat(2) triggers the dive because hpfs_getattr consults the allocation tree for the file size.

Reproduction evidence

Deterministic harness (harness.c)

A faithful userspace transcription of the exact dive: loop at hpfs_alsubr.c:78-110, against the exact on-disk struct layouts from hpfs.h (alblk_t 8 B, alnode_t 8 B, fnode.fn_abd[0x60], alsec.as_abd[0x1E0]). The harness has a depth-counter escape hatch (DEPTH_CAP) so it can OBSERVE the loop running forever instead of actually hanging. Three cases:

• Case 1 — cyclic image (A→B→A), UNPATCHED (DEPTH_CAP=1000): harness dives 1000 times A↔B before the cap trips → "WOULD LOOP FOREVER". This proves the kernel code has no cap and would loop forever.
• Case 2 — cyclic image (A→B→A), FIXED (DEPTH_CAP=HPFS_DIVE_MAX=20): harness trips at depth 20 → "EINVAL — dive cap tripped, loop broken". This proves the proposed fix closes the bug.
• Case 3 — control image (A→leaf AlSec), UNPATCHED: harness dives exactly 2 levels (fnode→A→leaf) and resolves bn=0 normally. This proves the CYCLE is the cause, not the image structure.

Output (run.log):

--- Case 1: cyclic image (A->B->A), UNPATCHED (no depth cap) ---
  [hpbmap] dive depth=0  node[0]: an_nextoff=0xffffffff an_lsn=0x60  (bn=0x0)
  [hpbmap] dive depth=1  node[0]: an_nextoff=0xffffffff an_lsn=0x80  (bn=0x0)
  [hpbmap] dive depth=2  node[0]: an_nextoff=0xffffffff an_lsn=0x60  (bn=0x0)
  ...A↔B bounce repeats...
  [hpbmap] dive depth=1000 node[0]: an_nextoff=0xffffffff an_lsn=0x60 (bn=0x0)
  [hpbmap] WOULD LOOP FOREVER: hit depth cap 1000 at bn=0x0
  result: DEPTH-CAP TRIPPED (kernel: would loop forever)

--- Case 2: cyclic image (A->B->A), FIXED (cap = HPFS_DIVE_MAX) ---
  result: EINVAL — dive cap tripped, loop broken (FIX WORKS)

--- Case 3: control image (A->leaf), UNPATCHED (proves cycle is cause) ---
  [hpbmap] dive depth=0  node[0]: an_nextoff=0xffffffff an_lsn=0x60  (bn=0x0)
  [hpbmap] dive depth=1  node[0]: an_nextoff=0xffffffff an_lsn=0x90  (bn=0x0)
  [hpbmap] dive depth=2  leaf[0]: al_off=0x0 al_len=0x80 al_lsn=0x91 (bn=0x0)
  [hpbmap] FOUND: bn=0x0 -> disk lsn 0x91 (depth=2)
  result: FOUND normally (loop terminated at leaf)

=== SUMMARY ===
DF_0858_BUG_CYCLIC_DIVE_LOOPS_FOREVER=1
DF_0858_FIX_DEPTH_CAP_BREAKS_LOOP=1
DF_0858_CONTROL_TERMINATES_NORMALLY=1
DF_0858_BUG_CONFIRMED=1

Live (DragonFly 6.5-DEVELOPMENT #0, X86_64_GENERIC, INVARIANTS ON)

craft_img.py builds an 80 KB minimal HPFS image (SuperBlock + SpareBlock + bitmap dir + bitmap band + root dir fnode + dirblk with one "FILE" dirent + a regular-file fnode whose fn_ab is AB_NODES with one AlNode pointing to AlSec A, plus AlSec A→B and AlSec B→A). Root mounts it; unprivileged user does cat /mnt/FILE:

mount_hpfs -o ro /dev/vn0 /mnt  → MOUNT_RC=0
(12-second timeout on `cat /mnt/FILE` as maxx → times out)
guest becomes unresponsive; vm.sh status ⇒ down

The guest wedged with NO panic in boot.log — exactly the signature of an unkillable kernel CPU spin (vs a panic, which would leave a fatal trap or panic: in boot.log). Only vm.sh reset with-src recovered. This is the unambiguous live DoS.

Exploit chain / impact ceiling

This bug produces a control-flow primitive (infinite kernel loop) but not a memory-corruption primitive. The dive loop only dereferences AlSec buffers and reads an_nextoff/an_lsn/al_off/al_len/al_lsn fields — it does not write attacker-controlled bytes anywhere. Therefore the Phase-6 escalation chain does not apply: the valid hard blocker "primitive is genuinely read-only / no write capability" applies (Phase 6 hard blocker #1).

Realistic impact ceiling:

1. Unkillable kernel CPU spin / hard DoS — a single cat or stat on the mounted cyclic image pegs one CPU at 100 % forever and the process cannot be killed (SIGKILL cannot deliver in kernel mode). The guest becomes unresponsive. Deterministic on the default GENERIC kernel.
2. No memory corruption ⇒ no info leak, no privilege escalation.

Fix (fix.diff)

Add a depth counter to hpfs_hpbmap() that is incremented at every dive: iteration. When the counter exceeds HPFS_DIVE_MAX (= 20 — far above any legitimate allocation-tree depth; each AlSec fan-out holds up to 60 AlNodes, so even a maximally-fragmented volume reaches only a handful of levels), log a kprintf and return EINVAL. This rejects cyclic or corrupt AlSec trees at the dive point instead of looping forever.

The fix is minimal (one logical change: depth counter + cap check at the dive label) and targeted at the confirmed root cause. It does not conflict with the DF-0857 fix (which validates ab_busycnt against the container max — an orthogonal issue); the two fixes are complementary.

Fix validation (Phase 8)

Applied fix.diff to in-guest /usr/src (patch -p1), rebuilt only the hpfs.ko KLD module (make in /usr/src/sys/vfs/hpfs), installed to /boot/kernel/hpfs.ko (sha256 d23a53566d6ddd0f8c80a1d261ddba7f554444a4f36748ef4b0153a243db6498), re-mounted the same cyclic image, re-ran cat /mnt/FILE (3× for determinism):

Fix closes the bug: the cyclic dive is now broken by the depth cap at depth 22 (2 levels past HPFS_DIVE_MAX=20 — fnode dive + AlSec A dive before the cap is checked at the second entry to dive:), hpfs_hpbmap returns EINVAL, cat returns immediately, the guest stays up, and the dmesg message clearly identifies the cyclic-or-corrupt tree. The fix is deterministic across 3 runs.

PoC changes

The runner created the entire evidence pack from scratch (the finding folder did not exist). Files authored: - README.md — finding summary, build/run, expected vs fixed behaviour - harness.c — deterministic dive-loop harness (faithful transcription + depth-counter escape + 3 cases: cyclic-bug, cyclic-fix, control) - craft_img.py — HPFS image crafter (cyclic AlSec A↔B and control A→leaf) - df858.img — crafted 80 KB HPFS image with cyclic A↔B (binary, for live test) - df858-control.img — control image: A→leaf AlSec (loop terminates normally) - build.sh / run.sh — exact repro scripts - fix.diff — git-apply-able fix: dive-depth cap (HPFS_DIVE_MAX=20) - build.log, run.log, fix_build.log, fix_run.log, env.txt — full logs - manifest.json — artifact catalog - VERDICT.md — this file