DF-3208 — cd9660 ihash publish-before-validate: race loser receives an

orphaned half-initialized VNON vnode (i_mnt == NULL) as SUCCESS → NULL-deref

panic in any subsequent VOP

What (root cause)

cd9660_vget_internal() (sys/vfs/isofs/cd9660/cd9660_vfsops.c:732-909) publishes the freshly allocated iso_node into the global inode hash (cd9660_ihashins(), cd9660_node.c:143-160) at vfsops.c:763 — before the on-media record is read and validated, and before i_mnt/i_devvp are set (vfsops.c:825-827). Every post-publish error path

• :775-779 lbn >= volume_space_size → ESTALE
• :781-787 off+34 > logical_block_size → ESTALE
• :789-797 bread() error → error
• :800-809 record crosses block boundary → ESTALE
• :837-840 relocated-path cd9660_devblkatoff() error → error

does vx_put(vp) without removing the node from the hash. Hash removal only happens in cd9660_reclaim() (cd9660_node.c:228), which runs at refcount 0 — but a concurrent cd9660_ihashget() for the same (dev, ino) already took a reference inside vget() (vfs_lock.c:589, ref before lock) and is blocked on the VX lock the creator holds. When the creator fails and releases, the waiter wakes, re-walks the hash (cd9660_node.c:124-130), finds the orphaned node still there, and returns it as a SUCCESS (cd9660_node.c:131-132). cd9660_vget_internal() then returns 0 with *vpp = a half-initialized vnode: v_type == VNON, i_mnt == NULL, i_devvp == NULL, iso_extent/i_size/inode.* == 0 (kmalloc M_ZERO, init at :825+ never ran).

The first VOP on that vnode dereferences NULL: cd9660_getattr() reads ip->i_mnt->im_fmask at cd9660_vnops.c:158 → kernel page fault → panic; read() likewise via blksize(imp=ip->i_mnt,...) in cd9660_read / cd9660_devblkatoff.

This is the cd9660 twin of the DF-3194 (NFS) "race-loser gets an unconnected VNON" class — but the failure mode is different and worse in shape: in DF-3194 the loser's own error path panicked on v_data == NULL; here cd9660_inactive()/cd9660_reclaim() explicitly tolerate ip == NULL (cd9660_node.c:199/205/227) and defuse that twin, while the handoff of the orphan returns SUCCESS and pushes the detonation into any later VOP.

Threat model

Crafted ISO9660/RRIP image, mounted (root setup or vfs.usermount=1 self-mount — same precondition family as DF-0878/DF-3146/DF-3156). After the mount, any unprivileged user with traverse permission races two lookups that resolve to the same crafted ino through two different parent directories (defeats the per-parent vnode lock taken by vop_compat_nresolve, kern/vfs_default.c:200) — e.g. directory entries "X/PWN" and "Y/PWN" both carrying an RRIP CL entry pointing beyond the device: rrip_pclink (cd9660_rrip.c:310-315) sets dp->i_ino = lba << 11, dp->i_ino != ino makes lookup pass relocated=1 (cd9660_lookup.c:366-367) and cd9660_devblkatoff(vp,0) at vfsops.c:837 fails (dscheck EINVAL/EIO on the beyond-device offset) → the :838 error path → poison window.

Panic (local DoS) when it fires; no memory corruption (all derefs are NULL reads at small offsets).

Dynamic verdict (see VERDICT.md)

not_reproduced — the static chain is proven link-by-link, and the failing path demonstrably executes on every attempt (~45k/s live: stat /mnt/x/X/PWN → EINVAL from vfsops.c:837-838 while the same CL pointing in-device makes stat succeed, proving the vget ran the relocated branch), but the race window cannot be opened on a stock system: cd9660 is not MPSAFE (VFS_SET(..., VFCF_READONLY) — no VFCF_MPSAFE), so every entry into vget_internal is serialized by the global mp_token (an LWKT token, sys/sys/mplock2.h). The token is only dropped when the holder blocks; lwkt_preempt() never releases a running thread's tokens (kern/lwkt_thread.c — preempt into/out of token holders is refused), and none of the reachable failure windows contains a voluntary block — the beyond-device bread fails synchronously via dscheck. ~80M attempted races across 6 configurations (up to 6 CPUs/6 threads, network interrupt pressure, 8-40 concurrent buffer-churn readers, and boot-tuned kern.nbuf of 1024 and 256 buffers to force geteblk allocator waits) produced no hit.

The window would open (and the chain become near-deterministic) whenever the in-window code blocks: genuinely failing-but-slow device I/O (real media errors, NFS-backed stores), an MPSAFE conversion of cd9660, or any future sleep added between ihashins and the error paths.

Reproduce (baseline attempt; guest must be up)

Host:

python3 craft_df3208.py df3208.iso
scp -F dfbsd-qemu/config df3208.iso trigger.c dfbsd:/root/
scp -F dfbsd-qemu/config craft_df3208.py dfbsd:/root/

Guest (root setup; trigger as nobody):

cc -O2 -pthread -o /root/trigger /root/trigger.c
chmod 755 /root/trigger
vnconfig -c /dev/vn0 /root/df3208.iso     # NOTE: no -S (see VERDICT.md)
mkdir -p /mnt/df3208 && mount_cd9660 /dev/vn0 /mnt/df3208
su -m nobody -c "/root/trigger /mnt/df3208 5000000 6"

Expected on a vulnerable+open window: kernel panic (Fatal trap 12, page fault in cd9660_getattr — NULL i_mnt). Observed on stock guest #0: EINVAL per attempt, no panic (window closed — see VERDICT.md).

Fix

fix.diff (authored post-verification, never applied to sys/): a new cd9660_ihashpurge(vp, ip) helper (unlink from hash, drop the devvp ref if taken, disconnect v_data, free the node) called on all five post-publish error paths, plus the now-mandatory vput(vp) before the goto loop retry in cd9660_ihashget() (with the purge, a successful vget can legitimately observe the node gone from the hash and must drop the lock+ref it holds).

DF-3208 — VERDICT

status: not_reproduced (dynamic) / static chain certain end-to-end by inspection and live partial demonstration.

The static chain (every link cited)

1. Publish before validate. cd9660_vget_internal(): - vfsops.c:745 ihashget miss → :749 getnewvnode (returns VX-locked, ref=1, v_type=VNON, v_data=NULL — kern/vfs_mount.c:194-221) → :754 kmalloc(M_ZERO) → :763 cd9660_ihashins() — node now globally visible → :769 vp->v_data = ip. - :771-823 (isodir==NULL: NFS fhtovp via VFS_VGET) validations, and :829-842 (relocated: cd9660_devblkatoff(vp,0)) can all fail after the publish; each error path does vx_put(vp) (vfs_lock.c:761-768) without touching the hash.
2. Hash removal only at reclaim. cd9660_ihashrem() is called only from cd9660_reclaim() (cd9660_node.c:228), which requires the vnode refcount to hit 0 (vnode_terminate → VOP_INACTIVE → vrecycle → vclean → VOP_RECLAIM, kern/vfs_subr.c:1284-1421).
3. The waiter's ref blocks the reclaim. A concurrent cd9660_ihashget(dev, ino) (cd9660_node.c:107-136) finds the node under the ihash token (:114-116), and vget() references before locking (kern/vfs_lock.c:589) then blocks on the creator's VX lockmgr. While blocked it holds a ref → creator's vx_put drops refcount 2→1 → no terminate, no reclaim, node stays in the hash.
4. The waiter receives the orphan as success. Creator's unlock wakes the waiter; vn_lock sees VRECLAIMED clear, vget returns 0; the post-block re-walk (:124-130) still finds the node (nobody removed it) → ihashget returns the half-initialized vnode → vget_internal returns 0 at :745-746 with *vpp = VNON / i_mnt==NULL / i_devvp==NULL / all-zero inode fields.
5. Detonation. Lookup hands it to namei as the resolved component (cd9660_lookup.c:360/375, vop_compat_nresolve kern/vfs_default.c:231-235); the first stat() → cd9660_getattr() reads ip->i_mnt->im_fmask (cd9660_vnops.c:158) → NULL-deref page fault → panic. Any other VOP (read, lookup-as-dir) is equally fatal.

Live partial demonstration (what was proven on the guest)

Stock INVARIANTS kernel #0, 6 vCPU, QEMU/KVM; crafted df3208.iso (sectors: PVD@16 with volume_space_size=0x200000, root@32, X@33, Y@34; X and Y each contain "PWN" — a directory record (flags=2) carrying RRIP PX + CL lba=0x1000, beyond the 40-sector device):

• CL → in-device (earlier 2GB-sparse image): stat /mnt/x/X/PWN succeeds with ino = 0x800000 (= 0x1000<<11) — proving the rrip_pclink → dp->i_ino → vget_internal(relocated=1) → devblkatoff path executes (it read the CL target and built the node from it).
• CL → beyond-device (80KB device): stat /mnt/x/X/PWN fails with EINVAL from vfsops.c:837-838 (devblkatoff bread of 0x800000 → dscheck) — i.e. the creator publishes the node and then fails on the intended path, ~45,000 times/second under the two-directory hammer.

Why it did not reproduce (the honest core)

cd9660 is not MPSAFE (VFS_SET(cd9660_vfsops, cd9660, VFCF_READONLY), cd9660_vfsops.c:97 — no VFCF_MPSAFE). Every entry into vget_internal (lookup via vop_old_lookup, NFS VFS_VGET, VFS_ROOT) is wrapped by VFS_MPLOCK() (kern/vfs_vopops.c:185-187) = lwkt_gettoken(&mp_token) (sys/sys/mplock2.h). Two facts close the window:

• Tokens are only released when the holder blocks (lwkt_switch → lwkt_relalltokens, kern/lwkt_thread.c:lwkt_switch). Interrupt preemption does not release them (lwkt_preempt() refuses to preempt into/out of token-holding threads — kern/lwkt_thread.c).
• None of the reachable failure windows contains a voluntary block. The failing bread at vfsops.c:837/:789 fails synchronously in the vn driver's dscheck (out-of-range I/O is rejected before any strategy I/O — sys/dev/disk/vn/vn.c:292-296); an in-range read never fails (so the relocated/validation paths either sleep-and-succeed or fail-without-sleeping). The only theoretical in-window sleep is getblk's buffer-allocation wait under free-list starvation.

Attempted window-openers, all negative:

Total ≈ 80M races. The buffer-churn configurations were meant to force geteblk waits inside the window; either the free list never empties at the failing getblk (virtio I/O is too fast; error buffers may also short- circuit subsequent breads) or the resulting block is too short for the handshake. Guest never panicked; every attempt returned EINVAL cleanly (and the transient node was reclaimed synchronously each time — no leak: vmstat-stable vnode counts across runs).

Conclusion: the defect is structural and provable by inspection; on a stock system the non-MPSAFE mp_token serializes all creators so the half-initialized node can never be observed by a second thread. The window opens whenever the in-window code blocks: genuinely failing-but-slow device I/O (real media errors, network-backed stores), an MPSAFE conversion of cd9660 (VFCF_MPSAFE), or any future sleep added between ihashins and the error paths. DF-3194 (NFS twin, not_reproduced for the same class of reason) is the precedent.

PoC notes (what had to be fixed vs the obvious sketch)

• -S 2048 in the DF-3146-era vnconfig recipe means 2048 MB device size, which silently grew the backing file to 2GB sparse and made every "beyond-device" offset in-device (reads succeed, zero-filled). Attached without -S (device = file size = 80KB).
• RRIP lookup derives a non-directory entry's ino from bp->b_bio1.bio_offset + entryoffsetinblock (cd9660_lookup.c:255-259), not isodirino — so the trigger entry must be a directory (flags=2) with a CL entry to steer dp->i_ino at an attacker-chosen LBA.
• Directory records need even-padded length ≥ 34+namelen (readdir rejects otherwise at cd9660_vnops.c:524) and RRIP-mount wants PX on entries to avoid "RRIP without PX" noise.
• Two different parent directories (X, Y) are required: same-directory lookups serialize on the parent vnode lock in vop_compat_nresolve (kern/vfs_default.c:200) before the mp_token is even taken.

Fix

fix.diff: cd9660_ihashpurge(vp, ip) on all five post-publish error paths (unlink from hash, vrele i_devvp if taken, v_data=NULL, kfree); vput(vp) added to cd9660_ihashget()'s ripped-out branch, which becomes reachable once purges exist (a successful vget can observe the node gone and must drop the lock+ref before retrying). Not applied to sys/; not kernel-built (baseline never reproduced, so fix validation is vacuous — fix_status: not_testable).

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.