DF-0865 — hpfs_validateparent dep-walk OOB read

Status: REPRODUCED (kernel panic / local DoS) → FIXED (validated single-module patch).

hpfs_validateparent() (sys/vfs/hpfs/hpfs_subr.c) walks directory entries inside a 2 KB bread buffer advancing a dep pointer by the on-disk de_reclen (u_int16_t, attacker-controlled) with no bound check, so a crafted HPFS image makes dep walk past the buffer → page-fault panic on the next dep->de_flag read. Triggered by an unprivileged stat() on a mounted malicious HPFS image. Same root cause as DF-0830 (duplicate on the hpfs_validateparent path). Read-only primitive → Medium (local DoS / heap info-leak ceiling), no escalation.

Reproduce

# 1. craft the image (host, needs python3)
python3 mk_hpfs.py evil.hpfs

# 2. on the guest, build the trigger (unprivileged user)
cc -O2 -o poc poc.c

# 3. root mounts the crafted image (realistic "admin mounts attacker image")
kldload hpfs                      # if not already loaded
vnconfig -c vn0 /path/to/evil.hpfs
mkdir -p /mnt/hpfs
mount -t hpfs -o ro /dev/vn0 /mnt/hpfs
chmod 755 /mnt/hpfs

# 4. unprivileged user triggers the bug
./poc /mnt/hpfs        # on unpatched kernel: guest panics (check boot.log)
                        # on patched kernel: stat returns EINVAL, no panic

Expected

• Unpatched #0 kernel: stat() does not return; guest wedges in DDB. Serial boot.log shows Fatal trap 12: page fault … Stopped at hpfs_validateparent+0x146: movzwl 0x2(%r15),%edx.
• Patched kernel (this fix.diff): stat() returns EINVAL, hpfs_validateparent: dep out of bounds appears in dmesg, guest stays up.

Files

• mk_hpfs.py — image crafter (root dir block dep0 de_reclen=0x0900).
• poc.c — stat() trigger for getattr → hpfs_validateparent.
• build.sh / run.sh — exact build/run commands.
• fix.diff — HPFS_DE_INBOUNDS macro + bounds on both validateparent while-loops + post-loop guards (git apply-able).
• VERDICT.md — full narrative + mechanism + fix validation.
• manifest.json — machine-readable artifact catalog.
• Logs: build.log, run.log (baseline panic), fix_build.log, fix_run.log (patched clean return), panic.txt, env.txt.

DF-0865 — hpfs_validateparent dep-walk OOB read past 2 KB bread buffer

Verdict: REPRODUCED — kernel panic (OOB read page fault) via crafted HPFS image; FIXED by the validated single-module patch.

The bug

hpfs_validateparent() in sys/vfs/hpfs/hpfs_subr.c reads a 2 KB directory block with bread(dhp->h_devvp, dbtodoff(lsn), D_BSIZE=2048, &bp) (line 556), then walks the hpfsdirent chain inside it advancing the pointer by dep->de_reclen:

• hpfs_subr.c:576 — dep = (hpfsdirent_t *)((caddr_t)dep + dep->de_reclen); (restore/olsn path)
• hpfs_subr.c:610 — dep = (hpfsdirent_t *)((caddr_t)dep + dep->de_reclen); (main walk)

de_reclen is a u_int16_t loaded directly from disk (sys/vfs/hpfs/hpfs.h:117) with no validation that dep stays within [bp->b_data, bp->b_data + D_BSIZE). After the loop, the post-loop read if(dep->de_flag & DE_DOWN) at line 613 also runs without a bounds check. A crafted directory block with a large de_reclen walks dep past the buffer; the next read of dep->de_flag faults.

Reachability (realistic, unprivileged)

hpfs_validateparent is called from hpfs_getattr (sys/vfs/hpfs/hpfs_vnops.c:467) when H_PARVALID is not yet set — i.e. on the first stat() of a vnode. The HPFS module is shipped loadable (/boot/kernel/hpfs.ko). The realistic threat model (acceptable precondition per the audit's realism test): an admin has mounted, or made mountable via vfs.usermount=1, an attacker-controlled HPFS image. Once mounted, any unprivileged user who can stat() a path on the mount triggers the bug — a standard syscall, no privilege check, no special device access. The malicious bytes live entirely in the filesystem image (directory-block content).

Mechanism (every hop cited)

1. sys/vfs/hpfs/hpfs.h:133 — D_BSIZE = DEV_BSIZE*4 = 2048.
2. sys/vfs/hpfs/hpfs_subr.c:556 — bread(..., D_BSIZE, &bp) reads a 2 KB directory block.
3. sys/vfs/hpfs/hpfs_subr.c:567 — dep = D_DIRENT(dp) = bp->b_data + sizeof(dirblk_t) (= 20). First dep at offset 20.
4. sys/vfs/hpfs/hpfs.h:116-131 — struct hpfsdirent: de_reclen is u_int16_t at offset 0, de_flag at offset 2 — both attacker-controlled from disk.
5. sys/vfs/hpfs/hpfs_subr.c:598-611 — main walk: while(!(dep->de_flag & DE_END)) { ... dep = dep + dep->de_reclen; } — no bounds check. With de_reclen=0x0900, dep jumps from bp->b_data+20 to bp->b_data+2324 — 276 bytes past the 2048-byte buffer.
6. sys/vfs/hpfs/hpfs_subr.c:613 — after the loop, if(dep->de_flag & DE_DOWN) reads dep->de_flag at the OOB address → page fault on unmapped page.
7. (The same unbounded stride exists at lines 572-577 in the olsn restore path and at line 588.)

Demonstration (baseline, unpatched #0 kernel)

mk_hpfs.py crafts a minimal-but-valid HPFS image whose root directory block contains a single dep with de_reclen=0x0900, de_flag=0x0000 (no DE_END, no DE_DOWN, de_fnode=0 so it never matches root's h_no). Mounting it and calling stat("/mnt/hpfs") (via poc.c) drives getattr → hpfs_validateparent over that block:

baseline (unpatched #0, original hpfs.ko):
  Fatal trap 12: page fault while in kernel mode
  fault virtual address    = 0xfffff80057f97116
  Stopped at  hpfs_validateparent+0x146:  movzwl  0x2(%r15),%edx

The instruction movzwl 0x2(%r15),%edx is reading dep->de_flag (offset +2) from the OOB dep pointer in r15. The fault address (...7116) is bp->b_data + 2324 + 2 — 278 bytes past the 2 KB buffer. Guest is wedged in DDB (db>). This is DF-0865's exact cited path.

Impact

• Kernel panic (local DoS). Deterministic, unprivileged, via a standard stat() syscall on a mounted malicious HPFS image. INVARIANTS is ON on the default X86_64_GENERIC kernel (options INVARIANTS); the OOB read faults before any INVARIANTS check could matter, so this is a default-kernel result, not a noinv-only one.
• Potential heap info-leak. If the OOB memory past the buffer were mapped (adjacent kernel heap), the walk would read dep->de_name / dep->de_namelen and, on a match at readdone: (hpfs_subr.c:632), bcopy(dep->de_name, hp->h_name, dep->de_namelen) would copy OOB heap bytes into hp->h_name, exposed to userspace as the filename via getattr. In this PoC the OOB page was unmapped, so the observable effect is the panic. (With a smaller / page-aligned de_reclen the leak is the realistic ceiling.)
• No write primitive. The dep-walk is read-only (reads dep fields, advances the pointer, and on success copies dep fields into hp). No corruption, no escalation chain to uid=0 is derivable. Correctly classified as Medium. (exploit_chain = none.)

Overlap with DF-0830

DF-0830 ("hpfs_readdir dep-walk unbounded") is the same root-cause defect across the three HPFS dep-walk sites: hpfs_readdir (vnops), hpfs_validateparent (subr), and hpfs_genlookupbyname (lookup). DF-0830's PoC crash actually landed in hpfs_validateparent+0x146 (the same site this finding cites), and DF-0830's proposed fix already patches all three sites including the two hpfs_subr.c loops cited here. DF-0865 is therefore a duplicate of DF-0830 on the hpfs_validateparent path. The fix.diff in this folder is the hpfs_validateparent-focused subset (the HPFS_DE_INBOUNDS macro + the two subr.c while-loop bounds + two post-loop guards) and is byte-identical to the hpfs.h + hpfs_subr.c hunks of DF-0830's fix.

Fix

fix.diff adds an HPFS_DE_INBOUNDS(bp, dep) macro to sys/vfs/hpfs/hpfs.h and applies it to both hpfs_validateparent dep-walk while-loops (hpfs_subr.c:572, :598) plus a post-loop guard before each dep->de_flag & DE_DOWN read (:579, :613). The macro checks that dep + sizeof(hpfsdirent_t) fits within bp->b_data + D_BSIZE before any dep field is read (short-circuit && in the while condition), and a de_reclen >= sizeof(hpfsdirent_t) term prevents the de_reclen=0 infinite loop. On an OOB dep, the function prints hpfs_validateparent: dep out of bounds and returns EINVAL instead of faulting.

Fix validation (Phase 8)

The bug is entirely in the loadable hpfs.ko module (both touched files hpfs.h and hpfs_subr.c compile into the module), so validation rebuilt only the module (cd /usr/src/sys/vfs/hpfs && make), installed it at /boot/kernel/hpfs.ko, and re-ran the identical PoC. The baseline panic is deterministic; the patched module survives 3/3 runs.

PoC changes

The folder was empty when this run started; the entire evidence pack was authored from scratch:

• mk_hpfs.py — Python crafter for a minimal-but-valid HPFS image whose root directory block has a dep with de_reclen=0x0900 (image structure reused from the proven DF-0829/DF-0830 layout).
• poc.c — calls stat() on the mountpoint to directly drive VOP_GETATTR → hpfs_getattr → hpfs_validateparent (the DF-0865-specific caller, vs DF-0830's getdents/readdir trigger).
• build.sh / run.sh — exact repro commands.
• fix.diff — the verified, git apply-able fix (macro + 2 while-loop bounds + 2 post-loop guards in hpfs_validateparent).