DF-0829 — HPFS EA ioctls walk past fn_int using unvalidated on-disk fn_ealen

Verdict: REPRODUCED — kernel heap info leak (KASLR-bypass class).

A crafted HPFS image whose root fnode lies about fn_ealen causes the extended-attribute ioctl handlers in sys/vfs/hpfs/hpfs_vnops.c (HPFSIOCGEANUM, HPFSIOCGEASZ, HPFSIOCRDEA) to walk past the 316-byte fn_int buffer and into the adjacent struct hpfsnode fields (h_vp, h_devvp, h_dev, h_no, …). HPFSIOCRDEA then copyouts attacker-sized bytes from that out-of-bounds region straight to userspace. There is no privilege check in hpfs_ioctl, so any local user with O_RDONLY on a vnode inside the mount can leak kernel pointers — defeating KASLR (relevant on hardened kernels; on this audit guest KASLR is already off, but the leak is real and reproducible).

Threat model (realistic)

Per the audit's realism test, the preconditions here are exactly the "attacker-controlled filesystem image" pattern called out as acceptable: - the HPFS module is loadable on the guest (/boot/kernel/hpfs.ko shipped with the install) and kldload'd by an admin — equivalent to an admin turning on any FS support; and - an admin has mounted / made mountable an attacker-controlled image.

Once mounted, the bug is reachable by any unprivileged user via a stock syscall (open + ioctl). No kldload/setuid-root helper/non-default kernel anywhere in the chain. HPFS is optional hpfs (loadable module), not in X86_64_GENERIC, so the realistic shape of this bug is "admin mounted an HPFS volume" — the same posture as every other FS-image-parsing finding in this audit.

Mechanism (every hop cited)

1. sys/vfs/hpfs/hpfs_vfsops.c:535 — bcopy(bp->b_data, &hp->h_fn, sizeof(struct fnode)) loads the on-disk fnode verbatim into the in-memory struct hpfsnode. fn_ealen (a u_int16_t at offset 56 in the kernel's C struct layout) is taken from disk with no validation.
2. sys/vfs/hpfs/hpfs_vnops.c:155, :189, :228 — the three EA ioctl handlers all share the same loop shape: c while (passed < hp->h_fn.fn_ealen) { eap = (struct ea *)((caddr_t)hp->h_fn.fn_int + passed); ... passed += sizeof(struct ea) + eap->ea_namelen + 1 + eap->ea_vallen; } fn_int is u_int8_t fn_int[0x13c] (316 bytes). The loop never bounds passed against sizeof(fn_int), so any fn_ealen > 0x13c (or an EA whose ea_namelen+1+ea_vallen is large enough to stride past fn_int) walks the eap pointer past the buffer.
3. sys/vfs/hpfs/hpfs_vnops.c:232-235 — HPFSIOCRDEA then does c rdeap->ea_sz = eap->ea_namelen + 1 + eap->ea_vallen; /* up to 65540 */ copyout(EA_NAME(eap), rdeap->ea_data, rdeap->ea_sz); EA_NAME(eap) = (char*)eap + sizeof(struct ea) is inside fn_int on the first iteration, but the copyout length is the attacker-controlled sum (up to 65540). That reads 65540 bytes starting inside fn_int, continuing past the end of struct fnode and into the live kernel pointers h_vp, h_devvp, h_dev, h_no, … that live immediately after h_fn in struct hpfsnode (sys/vfs/hpfs/hpfs.h:342-345).
4. The copyout return value is not checked (error = 0 is unconditionally assigned right after), so the ioctl reports success even when the oversized read faults part-way through.

Demonstration

Craft a minimal-but-valid HPFS image (mk_hpfs.py) whose root fnode has fn_ealen = 0xFFFF and a first EA at fn_int[0] with ea_namelen=5, ea_vallen=0xFFFE. Mount it, then issue HPFSIOCRDEA as the unprivileged maxx user:

$ ./poc /mnt/hpfs
[*] opened /mnt/hpfs fd=3, issuing HPFSIOCRDEA (ea_no=0)
[*] ioctl rc=0, returned ea_sz=65540, errno=0 (Success)
=== leaked heap (4096 bytes) ===
  [+0x0000] 0000004141414141     <- EA name "AAAAA" (our own data, in fn_int)
  ...
  [+0x0138] 8f52c78000000000     <- low half of next field past fn_int
  [+0x0140] 16fc2400fffff800     <- high half of h_vp
  ...
[+] plausible kernel pointers in first 4 KB: 3 (first at +0x13c = 0xfffff8008f52c780)
[!!!] DF-0829 CONFIRMED: kernel heap (pointers to h_vp/h_devvp/etc.) leaked

The leaked value at buffer offset 0x13c is exactly hp->h_vp (the struct vnode * set at hpfs_vfsops.c:507 after the bcopy), confirmed by the kernel layout (sizeof(struct hpfsnode)=912, h_fn at offset 56, fn_int at offset 200 within h_fn, h_vp at offset 576 of struct hpfsnode ⇒ distance 576 - (56+200+4) = 316 = 0x13c). Across three fresh-mount runs the value changes (0xfffff8008f52c780, 0xfffff8008f52c480, 0xfffff8008f52c300), proving it is a real heap-address leak and not a constant.

Impact

• Info leak / KASLR bypass. Leaks 3 plausible kernel pointers per call (h_vp, h_devvp, and one of h_dev/h_no) — enough to defeat KASLR on a kernel that has it.
• OOB read. Up to ~64 KB of kernel heap is exposed per call (bounded only by the u_int16_t sums; in practice copyout faults at the first unmapped page, returning whatever it copied first).
• No privilege check in hpfs_ioctl — any local user with O_RDONLY on a vnode inside an HPFS mount.

No write primitive is implied by this bug — it is a pure read OOB. There is therefore no escalation chain to uid=0 to develop; the realistic impact ceiling is kernel-pointer leak / KASLR defeat (correctly classified as Medium in the finding).

PoC changes from the seeded draft

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

• mk_hpfs.py — Python crafter for a minimal-but-valid HPFS image with a lying fn_ealen=0xFFFF. The non-obvious part: the kernel C struct layout (verified with a tiny kldload module) has natural-alignment padding, so fn_ealen lives at byte 56 of struct fnode (not 52) and fn_flag at byte 59 (not 55). The image also has to provide a minimal dir block + alleaf_t so hpfs_validateparent (called from hpfs_getattr during stat) doesn't EINVAL out before the PoC can even open the mountpoint.
• poc.c / hpfs_ioctl.h — opens /mnt/hpfs O_RDONLY and issues HPFSIOCRDEA, then scans the returned buffer for canonical kernel pointers (0xffff_xxxx_xxxx_xxxx).
• sz.c — userspace mirror of struct fnode/sublock/spblock used while debugging byte offsets; kept for reproducibility.
• fix.diff — verified one-liner per-handler clamp + a load-time clamp.
• build.sh / run.sh — exact reproduce commands.

Recommended fix

Clamp fn_ealen against sizeof(fn_int) (a) at fnode load (hpfs_vfsops.c:535) so the rest of the kernel never sees a lying value, and (b) defensively inside each ioctl loop (hpfs_vnops.c) so an already-cached lying value cannot be walked either. The full git apply-able diff is in fix.diff (supersedes the finding markdown's proposal — see recommended_fix).

Fix validation (Phase 8)

The first fix attempt (load-time clamp only) failed: it capped the loop-iteration count to sizeof(fn_int), but the copyout() inside the loop still read eap->ea_namelen + 1 + eap->ea_vallen = 65540 bytes from inside fn_int on the first iteration — i.e. the same leak, just single-iteration. This was caught by actually building and booting the patched kernel and re-running the PoC (which still printed ea_sz=65540 and leaked 3 kernel pointers), exactly the failure mode Phase 8 is designed to catch.

The revised fix.diff adds an HPFS_EA_FITS() check that stops the loop the moment the current EA's header or name/value span would extend past sizeof(fn_int) — so every byte the loop reads (and every byte copyout() forwards) is provably inside fn_int.

fix_status: fixed. The patched kernel boots, the PoC cleanly fails with ENOENT (no EA fits in the bounded fn_int), and zero kernel pointers are returned across three independent runs.