DF-3253 — hpfs_hphashvget hands out half-initialized H_INVAL hpfsnodes (publish-before-validate race)

What

hpfs_vget (sys/vfs/hpfs/hpfs_vfsops.c:456-552) publishes the freshly kmalloc'd hpfsnode into the global inode hash — hpfs_hphashins(hp) at hpfs_vfsops.c:525 — BEFORE validating it:

525:    hpfs_hphashins(hp);                       /* published */
527:    LOCKMGR(&hpfs_hphash_lock, LK_RELEASE);
529:    error = bread(hpmp->hpm_devvp, dbtodoff(ino), FNODESIZE, &bp);
530:    if (error) { kprintf(...); vx_put(vp); return (error); }   /* still hashed */
535:    bcopy(bp->b_data, &hp->h_fn, sizeof(struct fnode));
538:    if (hp->h_fn.fn_magic != FN_MAGIC) {
539:        kprintf("hpfs_vget: MAGIC DOESN'T MATCH\n");
540:        vx_put(vp); return (EINVAL);          /* still hashed */

Both error paths drop the vnode and return without unhashing the node. The node is marked H_INVAL (set at :506, cleared only at :545 after validation), and in the bread-failure case h_fn is uninitialized kernel heap (kmalloc at :488, never zeroed).

hpfs_hphashvget (sys/vfs/hpfs/hpfs_hash.c:104-139, the audited file) finds such a node, blocks in vget(vp, LK_EXCLUSIVE) on the creator's VX lock, and — when the failing creator vx_put()s — wakes up and returns the poisoned vnode as a successful lookup without ever checking h_flag & H_INVAL (its re-walk at :122-129 verifies identity only). vget() takes its reference before blocking (sys/kern/vfs_lock.c:589), so the creator's vx_put cannot reclaim the node under the waiter.

hpfs_lookup (hpfs_vnops.c:1056) returns the poisoned vp to namei; hpfs_getattr (hpfs_vnops.c:463) then exposes vap->va_size = hp->h_fn.fn_size — bytes from the fnode the kernel itself just rejected (badmagic) or from uninitialized kernel heap (bread failure) — as a successful stat() of a file that can NEVER be looked up sequentially (every non-racing lookup fails EINVAL).

Threat model: crafted HPFS image (attacker controls fnode magic / image truncation makes bread fail) + any local user racing lookups on the mounted fs. Unprivileged trigger (uid 1001). Same class as DF-3251 (ext2 publish-before-validate twin); hpfs_hash.c is the validation omission site.

PoC

• craft_df3253.py <out.img> <badmagic|trunc> — minimal crafted HPFS image (root fnode @0x20 -> dirblk @0x40 -> dirent "ZFILE" -> fnode @0x58). badmagic: fnode magic = 0xDEADBEEF, fn_size = 0x00BADF00D (marker). trunc: image ends before 0x58 so bread fails -> h_fn stays uninitialized heap.
• poc.c — N threads racing stat() of the always-rejected file. Sequentially stat can only return EINVAL. Any stat()==0 (printed as RACE WIN, with st_size=0x00BADF00D for badmagic, or varying heap garbage for trunc) is the poisoned handoff.

Run (exact)

./build.sh                       # compile poc + mount helper in guest
./run.sh badmagic                # or: ./run.sh trunc
# custom: NTHR=8 ITERS=300 REPS=3 ./run.sh badmagic

Expected output (instrumented kernel, see VERDICT.md)

UTIMES WIN tid2 pathA: utimes()=0 on a fnode the kernel ALWAYS rejects (poisoned handoff confirmed)
DF-3253 SUMMARY: wins=19 einval=37 ebadf(poisoned handoffs seen by stat)=19 enoent=0 other=0
DF-3253 VERDICT: POISONED H_INVAL HPFSNODE HANDED OUT BY hpfs_hphashvget — RACE CONFIRMED

Note: stat() itself cannot return 0 on the stock failure paths — the failed creator never sets v_type, so the handed-off VNON vnode reaches cvn_stat's type switch (sys/kern/vfs_vnops.c:894 default: return (EBADF)) and stat fails EBADF (the normal failure is EINVAL from vget; EBADF is the handoff signature). The syscall-success proof is utimes()==0 (hpfs_setattr's utimes path has no v_type check), which also mutates the rejected inode (H_PARCHANGE). Kernel console shows DF3253H: *** INVAL HANDOFF #N *** per handoff; ~half the runs panic at the cleanup umount (panic: unmount: dangling vnode). With fix.diff applied: wins=0 ... ebadf=0 einval=960, UMOUNT_OK.

Why an instrumented kernel

On the stock kernel the post-publish window is bread(cache-hit)+bcopy — sub-microsecond — while every failed lookup costs two serial-console kprintfs (~60ms), so the waiter almost never lands inside the window under console-lock serialization (0 wins in ~750 real iterations). The real-world window is the bread itself: a cold fnode read on rotating media / a stalled device is 5-20ms. The guest kernel is therefore instrumented (instrument_applied.diff, guest-only, never in the audit sys/ tree) with a 10ms tsleep inside the two failure paths — labeled DF3253 — reproducing cold-I/O latency. The fix validation runs on the SAME instrumented kernel: the window stays 10ms, the fix must still yield zero handoffs.

DF-3253 — VERDICT

Status: REPRODUCED (poisoned H_INVAL hpfsnode handoff via hpfs_hphashvget, unprivileged, crafted HPFS image) — plus a demonstrated secondary consequence: kernel panic (unmount: dangling vnode) on the subsequent umount in 2 of 4 racing runs. Fix validated on the same instrumented kernel: handoffs 0, 960/960 lookups fail EINVAL, umount clean.

Root cause (line-accurate)

hpfs_vget (sys/vfs/hpfs/hpfs_vfsops.c:456-552):

• :488 hp = kmalloc(sizeof(struct hpfsnode), M_HPFSNO, M_WAITOK) — not zeroed
• :506 hp->h_flag = H_INVAL;
• :525 hpfs_hphashins(hp); — published into the global inode hash
• :527 lockmgr release
• :529 error = bread(...) — fails (truncated image) → :532 vx_put(vp); return (error); — node stays hashed, h_fn is uninitialized kernel heap
• :538 if (hp->h_fn.fn_magic != FN_MAGIC) → :540 vx_put(vp); return (EINVAL); — node stays hashed with the rejected fnode
• H_INVAL is cleared only at :545 on the success path; vp->v_type is set only at :544 — failed creators leave v_type == VNON.

hpfs_hphashvget (sys/vfs/hpfs/hpfs_hash.c:104-139 — the audited file):

• :111-113 a concurrent lookup finds the published node,
• :116 vget(vp, LK_EXCLUSIVE) blocks on the creator's VX lock — the waiter's reference is taken at sys/kern/vfs_lock.c:589 BEFORE vn_lock, so the creator's vx_put cannot reclaim the node under it,
• :122-129 post-wake re-walk verifies identity only — h_flag & H_INVAL is never checked — and the half-initialized vnode is returned as a successful lookup result at :135.

hpfs_lookup (hpfs_vnops.c:1056) hands it to namei without further checks. hpfs_getattr (hpfs_vnops.c:463) then computes va_size = hp->h_fn.fn_size from the rejected/uninitialized fnode.

Race shape (empirically established)

namei holds the directory vnode lock across VOP_LOOKUP, so lookups within ONE directory are serialized and can never race (measured: 1451 publishes, 0 waiter hash-hits with a single-directory PoC). The handoff requires two concurrent VFS_VGET()s for the SAME fnode through DIFFERENT directories — provided directly by a crafted image with two dirents (A/ZFILE, B/WFILE) both pointing at fnode 0x58. Nothing in HPFS cross-locks those two paths.

Demonstration (guest, stock INVARIANTS kernel #2 + labeled instruments)

Instruments (guest-only, never in the audit tree): 10ms tsleep in the two failure paths (simulating cold-fnode bread latency; real-world 5-20ms on rotating/stalled media) + counters/prints in hphashvget (DF3253H) and at publish (DF3253P).

PoC: 8 threads × 120 stat()s alternating between the two paths, as uid 1001 on a vn(4)-mounted crafted image (mount by root via mount_rw).

Baseline results (3 independent runs):

• DF-3253 SUMMARY: wins=40 einval=0 ebadf(poisoned handoffs seen by stat)=40 and wins=19 ... ebadf=19 — every stat that did not become a fresh creator received a poisoned vnode (kernel counter INVAL HANDOFF matches; console shows vget OK → *** INVAL HANDOFF #N ***).
• UTIMES WIN tidN pathX: utimes()=0 on a fnode the kernel ALWAYS rejects (27 printed in one run) — full syscall SUCCESS (hpfs_setattr utimes path, hpfs_vnops.c:530-544, has no v_type check) on a fnode whose lookup can only ever fail — it also sets H_PARCHANGE on the poisoned node (kernel state mutated through the rejected fnode).
• stat() itself returns EBADF: the poisoned vnode reaches cvn_stat's vp->v_type switch (sys/kern/vfs_vnops.c:894-895 default: return (EBADF)) because v_type was never initialized — i.e. the EBADF is itself the signature that a VNON vnode was returned by a SUCCESSFUL lookup (the normal failure is EINVAL from vget).
• Panic: 2 of 4 racing runs ended with panic: unmount: dangling vnode (dounmount → vflush unable to drain the poisoned/mutated vnodes) — local kernel DoS. Console evidence: panic.console.txt, panic2.console.txt (both show INVAL HANDOFF #N immediately before the panic), plus one clean-umount baseline (run.baseline3).

Uninitialized-heap nuance (trunc variant, bread fails at :529): same publish window and same handoff mechanics (identical code path); h_fn holds stale kernel heap that hpfs_getattr reads (fn_size, fn_parent walk). Direct byte disclosure to userspace is blocked on this path by the VNON abort in cvn_stat; the heap bytes still drive kernel-side metadata interpretation (validateparent walk, va_size/va_bytes computation). Not separately re-run — the badmagic variant exercises the identical two error paths.

Fix validation (same instrumented kernel #2, module swap only)

fix.diff = (a) hpfs_hphashrem(hp) on BOTH post-publish error paths in hpfs_vget (load-bearing half — validated alone: forced full module rebuild, 0 handoffs) + (b) H_INVAL re-check/retry in hpfs_hphashvget after the identity re-walk (defense-in-depth).

Identical PoC, identical 10ms window: with the fix the previously observed behavior is GONE — every lookup fails EINVAL (the only legitimate outcome), no handoffs (kernel counter 0), unmount clean.

Honest limits

• The stat()==0-with-attacker-size observable is NOT achievable on the stock failure paths (v_type is never set on failure → cvn_stat aborts EBADF); the demonstrated syscall-success observable is utimes()==0 on the rejected fnode, which is strictly stronger as an integrity signal.
• The dangling-vnode panic reproduced 2/4 times (timing-dependent vnode lifecycle after handoff + PARCHANGE mutation); root-cause of which vnode dangles was not further dissected (ddb session not interactive through this harness).
• Attack preconditions: crafted HPFS image mounted (root or usermount) + local unprivileged user racing lookups; the 10ms validation window is instrument-supplied in the demo but is the natural bread latency of any cold/stalled device (and grows without bound on a slow/erroring reader).

Impact

Unprivileged local user on a system with an attacker-influenced HPFS mount: (1) successful VFS lookups returning half-initialized/rejected inodes — rejected-metadata integrity bypass (utimes/metadata mutations on inodes the kernel itself refuses) and uninitialized-kernel-heap-driven metadata walks; (2) kernel panic at umount (local DoS). No user→root chain demonstrated (read-side/type-confusion primitive; no controlled write). Severity Medium (matches the DF-3251 ext2 twin class), bucket base:vfs.

Fix status (batch validation)

Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.