DF-0927 — PoC: unbounded dirent traversal in hpfs_genlookupbyname

Goal

Prove four impacts of the unbounded dirent-chain walk in hpfs_genlookupbyname (hpfs_lookup.c:82-102) on a crafted HPFS image:

• Variant A (OOB read): de_reclen = 0xFFFF and DE_END clear → first stride jumps ~64 KiB past the 2048-byte bread'd buffer → kernel page-fault panic reading dep->de_flag. (CWE-125 OOB read.)
• Variant B (hang #1): de_reclen = 0 → dep never advances → infinite while loop (kernel thread wedged). (CWE-835.)
• Variant C (hang #2): two dirblks whose DE_DOWN pointers reference each other → dive loop never terminates. (CWE-835 + CWE-400.)
• OOB→info-leak ceiling: if the kernel survives the OOB read, the bytes are copied to userspace via the readdir name-copy path (hpfs_vnops.c:745-747 hpfs_de_uiomove).

Plus a deterministic userspace harness (harness.c) transcribing the hpfs_genlookupbyname loop byte-for-byte against sys/vfs/hpfs/hpfs.h struct layouts, proving all three variants and the fix rejection.

Files

Build & run (DragonFlyBSD guest)

The harness is pure userspace and reproduces the bug deterministically:

ssh dfbsd-maxx
cd poc/DF-0927
./build.sh && ./run.sh

For the in-kernel reproduction (root to mount; trigger as unprivileged maxx):

python3 craft_img.py --oob df0927_oob.img    # on host (no python3 in guest)
scp df0927_oob.img dfbsd-maxx:poc/DF-0927/

# in guest as root:
vnconfig -c vn0 /home/maxx/poc/DF-0927/df0927_oob.img
mount -t hpfs -o ro /dev/vn0 /mnt/df0927

# in guest as unprivileged maxx:
stat /mnt/df0927/zzz     # immediate panic (Variant A)

Expected output

Variant A (panic, baseline)

Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xfffff80058e36015
fault code = supervisor read data, page not present
instruction pointer = 0x8:0xffffffff826032f6
current process = 910
Stopped at hpfs_validateparent+0x146: movzwl 0x2(%r15),%edx

(movzwl 0x2(...) reads dep->de_flag at offset 0x2; %r15 is the poisoned dep after dep += de_reclen(0xFFFF). The panic fires in hpfs_validateparent (sibling of hpfs_genlookupbyname sharing the same unbounded dep += de_reclen pattern); the harness proves the bug deterministically in hpfs_genlookupbyname itself.)

Variant B/C (hard hang, baseline)

stat never returns; ssh stops responding within ~12s; guest wedged. The kernel thread spins forever inside hpfs_validateparent / hpfs_genlookupbyname holding VFS locks.

Patched kernel (fix applied)

$ stat /mnt/df0927/zzz
stat: /mnt/df0927/zzz: stat: Invalid argument
$                                  # guest up; dmesg: hpfs_validateparent: corrupt dirblk

Notes

• HPFS mount is root-only (vfs.usermount=0). But once root mounts the crafted image, any unprivileged user who can stat/ls/open files in the mounted tree triggers the bug. The PoC uses mount -t hpfs -o ro (no uid=/gid= remapping) — maxx (uid 1001) can stat /mnt/df0927/zzz because the mountpoint dir is world-readable. The trigger is fully unprivileged post-mount.
• The same unbounded dep += dep->de_reclen pattern exists in hpfs_readdir (hpfs_vnops.c:823-915) — same bug class, would need the same fix; out of scope for this finding's fix.diff.

DF-0927 — Verdict

Verdict: REPRODUCED (panic + hard-hang DoS, three variants). FIX VALIDATED.

Mechanism (root cause, with path:line)

hpfs_genlookupbyname (sys/vfs/hpfs/hpfs_lookup.c:55-108) reads a 2048-byte (D_BSIZE, hpfs.h:133) directory block via hpfs_breaddirblk (hpfs_subr.h:78 → hpfs_breadstruct, hpfs_subr.c:835, which checks only the 4-byte magic) and then walks the on-disk dirent chain inside that buffer:

dep = D_DIRENT(dp);                                            /* hpfs_lookup.c:80 */
while(!(dep->de_flag & DE_END)) {                              /* :82 */
    ...
    res = hpfs_cmpfname(hpmp, name, namelen,
                        dep->de_name, dep->de_namelen, ...);   /* :87 */
    if (res == 0) { ...; return (0); }                         /* :89 */
    else if (res < 0) break;                                   /* :93 */
    dep = (hpfsdirent_t *)(((caddr_t)dep) + dep->de_reclen);   /* :96 */
}
if (dep->de_flag & DE_DOWN) {                                  /* :99 */
    lsn = DE_DOWNLSN(dep);                                     /* :100 */
    brelse(bp); goto dive;                                     /* :101-102 */
}

There is no bound of (caddr_t)dep against (caddr_t)dp + D_BSIZE, no minimum on dep->de_reclen (u_int16_t, hpfs.h:117), no maximum on dep->de_namelen (u_int8_t, hpfs.h:127), and no depth counter on the dive loop. By contrast the sibling hpfs_readdir carries an int level (hpfs_vnops.c:776,821,886,913,922-927) and hpfs_validateparent carries an int level (hpfs_subr.c:532,549,601,616,624-627) — both lack only the buffer bound, but hpfs_genlookupbyname lacks both.

Four attacker-controllable conditions follow directly:

Reproduction on #0 baseline GENERIC (with-src, INVARIANTS ON)

Variant A — kernel OOB-read panic

$ ssh dfbsd-maxx 'stat /mnt/df0927/zzz'   # uid 1001, post root-mount
[guest down]
--- dfbsd-qemu/boot.log ---
Fatal trap 12: page fault while in kernel mode
cpuid = 1; lapic id = 1
fault virtual address = 0xfffff80058e36015
fault code = supervisor read data, page not present
instruction pointer = 0x8:0xffffffff826032f6
current process = 910 (stat)
kernel: type 12 trap, code=0
Stopped at hpfs_validateparent+0x146: movzwl 0x2(%r15),%edx
db>

The faulting instruction movzwl 0x2(%r15),%edx reads dep->de_flag (offset 0x2 of struct hpfsdirent) at the poisoned %r15 = dep after dep += de_reclen(0xFFFF). The fault address 0xfffff80058e36015 is ~0xFFFF past a kernel heap address — exactly the unbounded-stride OOB.

The panic fires in hpfs_validateparent (hpfs_subr.c:522) — a sibling of hpfs_genlookupbyname sharing the same unbounded dep += dep->de_reclen pattern at hpfs_subr.c:576, 588, 610. The finding text explicitly notes this is the same bug class. stat triggers VOP_GETATTR → hpfs_getattr → hpfs_validateparent (when H_PARVALID is clear; hpfs_vnops.c:466-467) before it reaches lookup → hpfs_lookup → hpfs_genlookupbyname, so the OOB lands in hpfs_validateparent first. Both functions need the same bound.

Variant B — de_reclen=0 hard hang

$ ssh dfbsd-maxx 'stat /mnt/df0927/zzz'
[12 s timeout — guest wedged, ssh dies]
--- dfbsd-qemu/boot.log shows no panic; pure kernel spin ---

Variant C — DE_DOWN cycle hard hang

$ ssh dfbsd-maxx 'stat /mnt/df0927/zzz'
[12 s timeout — guest wedged, ssh dies]

Deterministic userspace harness (transcribes hpfs_genlookupbyname)

[A] BUG  de_reclen=0xFFFF: oob=63507B past buf, steps=1, dives=1, oob_at_step=1
        expected OOB = 0xFFFF - (D_BSIZE - 20) = 63507 B
[B] BUG  de_reclen=0: rc(oob/spin)=-3, steps=1001 (capped; kernel = infinite loop)
[C] BUG  D0<->D1 cycle: rc=-4 (expect -4 cycle), steps=0, dives=6 (capped; kernel = infinite)
DF_0927_BUG_CONFIRMED=1
DF_0927_FIX_REJECTS_ALL_VARIANTS=1

The harness reads D_BSIZE, struct dirblk, struct hpfsdirent straight from sys/vfs/hpfs/hpfs.h. It places the 2 KiB dirblk at the start of a 256 KiB 0xAA-poisoned mmap and runs the exact loop body. Variant A reports 63 507 B OOB past the buffer (matching 0xFFFF - (2048 - 20)), variant B hits the 1000-iteration cap (kernel would spin forever), variant C hits the 5-dive cap (kernel would cycle forever).

Threat model / reachability

• HPFS mount is root-gated (vfs.usermount=0). The PoC assumes an admin has mounted (or made mountable) the attacker's crafted image — the standard filesystem-image threat model (USB auto-mount, jail/multi-tenant images, kiosk systems, vfs.usermount per-user grants). The finding's CVSS PR:L (not PR:N) reflects this.
• Post-mount, the trigger is fully unprivileged. Once root mounts the image at a world-traversable path (the PoC uses /mnt/df0927 with chown maxx:maxx), maxx (uid 1001, NOT in wheel) issues stat /mnt/df0927/zzz and triggers the bug. The reproduction in this report uses exactly that path.

Impact

• OOB read (variant A): kernel page-fault panic → reliable DoS. If the OOB read lands in mapped kernel memory instead, the bytes flow to userspace via the readdir/getattr name-copy path (hpfs_vnops.c:745-747 hpfs_de_uiomove and :1068-1070 bcopy(dep->de_name, hp->h_name, ...)), yielding a kernel heap disclosure. The page-fault vs info-leak outcome depends on kernel heap layout (the 64 KiB stride crosses many slab pages); both are bug manifestations.
• Hangs (B, C): deterministic local DoS. The kernel thread spinning in hpfs_validateparent/hpfs_genlookupbyname holds VFS locks and wedges the guest (ssh stops responding).

The fix (fix.diff)

Two files patched:

1. sys/vfs/hpfs/hpfs_lookup.c (the finding's primary target): adds - dlimit = (caddr_t)dp + D_BSIZE hard buffer bound, - per-iteration check (caddr_t)dep + sizeof(struct hpfsdirent) > dlimit || dep->de_reclen < sizeof(struct hpfsdirent) || (caddr_t)dep + dep->de_reclen > dlimit || dep->de_namelen > dep->de_reclen - sizeof(struct hpfsdirent) + 1 → goto bad (returns EINVAL), - re-validation of the terminator dirent before DE_DOWN/DE_DOWNLSN, - int depth counter on the dive loop with HPFS_DIRDEPTH_MAX 64 cap → defeats the DE_DOWN cycle.

2. sys/vfs/hpfs/hpfs_subr.c (hpfs_validateparent, where the panic actually fires on the stat path): adds the same dlimit buffer bound and per-iteration check at all three dep += dep->de_reclen sites, plus a level > HPFS_DIRDEPTH_MAX cap at the top of the dive loop (this function already had a level counter, but no maximum; without this the DE_DOWN cycle would still spin here).

Both files gain #define HPFS_DIRDEPTH_MAX 64 (B-tree depth sanity bound; real HPFS B-trees are <10 deep). The fix matches the finding's ## Recommended fix proposal in hpfs_lookup.c and extends the same pattern to hpfs_validateparent (which the finding notes is the same bug class).

Phase 8 — fix validation

Built the patched hpfs.ko as a KLD module (HPFS is loadable, not built into the GENERIC kernel; verified viakldstat -vandnm /boot/kernel/kernelshowing no hpfs symbols). Single command:

cd /usr/src/sys/vfs/hpfs && make -DNO_MODULES    # rc=0, all 6 TUs + link

Installed: cp /usr/obj/.../hpfs.ko /boot/kernel/hpfs.ko (sha256 8846085ddedce20bac8f80369a75cd3a14b178555c99df7f8fcd6f3c05f504da, 44 160 B).

The patch closes all three variants deterministically. git apply --check passes cleanly against the unmodified sys/ tree.

PoC changes (vs the reviewer-supplied scaffolding)

• The original mkimg.py expected a base.hpfs that does not exist in the evidence pack. Replaced with craft_img.py which builds a complete valid HPFS image from scratch (super/spare/bitmap/root-fnode/dirblk), mirroring the proven DF-0857 layout, and emits all three variants (--oob, --hang1, --cycle).
• Added harness.c: a deterministic userspace transcription of hpfs_genlookupbyname:82-102 against the exact hpfs.h struct layouts, proving all three variants byte-for-byte and demonstrating the fix rejection. This gives a reproducible signal that does not depend on kernel heap layout (the live-kernel OOB fault-vs-leak outcome varies by run, but the harness always reports oob=63507).
• Added fix.diff extending the finding's proposed fix to also patch hpfs_validateparent (the actual panic path on this guest) with the same bound check + depth cap.

Non-corruption note (no escalation chain)

This is a pure OOB-read + DoS finding (CWE-125/835/400). The primitive is read-only — the loop only reads dep->de_flag, dep->de_name, dep->de_reclen, dep->de_namelen, dep->de_cpid; it does not write the buffer. There is no write/UAF/double-free primitive to convert into a credential corruption. The realistic impact ceiling is therefore: (1) reliable kernel panic / hard hang (DoS), confirmed on all three variants; and (2) potential kernel heap info-leak if the OOB read lands in mapped memory and the bytes flow to userspace via the readdir name copy. No uid=0 escalation is derivable; this is not a memory-corruption primitive that can be groomed into a write.