DF-3241 — ufs_check_export / ufs_fhtovp reachable with mnt_data == NULL in the dounmount fsid window

File under audit: sys/vfs/ufs/ufs_vfsops.c (pass 2) Kernel: DragonFly 6.5-DEVELOPMENT #0 (X86_64_GENERIC, INVARIANTS), stock in-guest build

What the bug is

dounmount() (sys/kern/vfs_syscalls.c) tears a mount down in this order:

1. VFS_UNMOUNT() — ffs_unmount() frees the struct ufsmount, sets mp->mnt_data = 0 (sys/vfs/ufs/ffs_vfsops.c:862-866)
2. … journal cleanup, vnode-op teardown, cache drops …
3. mountlist_remove(mp) (sys/kern/vfs_syscalls.c:1040) — only NOW does the mount leave the fsid RB-tree.

Between (1) and (3) the mount is still resolvable by fsid through vfs_getvfs() (sys/kern/vfs_mount.c:413-424), which does not check MNTK_UNMOUNT. Every fsid consumer then feeds the still-listed mount into the UFS file-handle path:

• nfsrv_fhtovp() (sys/vfs/nfs/nfs_subs.c:1235-1246) — unauthenticated remote/local whenever an exported UFS exists and nfsd is running: VFS_CHECKEXP → ufs_check_export() derefs VFSTOUFS(mp)->um_export on a NULL mnt_data (sys/vfs/ufs/ufs_vfsops.c:242-246), then VFS_FHTOVP → ffs_fhtovp() reads VFSTOUFS(mp)->um_fs at NULL+0x18 (sys/vfs/ufs/ffs_vfsops.c:1216-1218).
• fhopen/fhstat/fhstatfs/fhstatvfs (sys/kern/vfs_syscalls.c:4856, 5024, 5072, 5133) — root-gated in-kernel repro path (used by this PoC).
• kern_checkpoint (sys/kern/kern_checkpoint.c:496).

Result: deterministic Fatal trap 12, supervisor read at 0x18 in ffs_fhtovp (kernel NULL-deref panic). This is the UFS twin of DF-3236 (devfs fhtovp NULL lock) and DF-3207 (nullfs mnt_data).

Files

• getfh.c — capture an fhandle_t (root; getfh(2))
• fhbomb.c — spin fhstat(2) on the captured handle (root; fhstat is root-gated)
• fhstat_once.c— sanity: fh must resolve while mounted
• race.sh — vn(4) + newfs UFS setup, N fhstat spinners, mount/umount -f loop
• build.sh — host-side: push + compile in guest
• run.sh — host-side: run the race, watch for the panic
• panic.txt — serial console capture of the fatal trap (baseline)
• build.log — kernel build log for the fix validation
• run.fix.log — patched-kernel rerun (must survive)
• fix.diff — root-cause fix: vfs_getvfs() refuses mounts with MNTK_UNMOUNT

Reproduce

# build
./build.sh
# run (as root, in guest):     ROUNDS=4000 NBOMB=8 sh /root/poc/race.sh
# host-side driver:
./run.sh

Expected (stock kernel): panic within seconds-to-minutes:

Fatal user address access from kernel mode from fhbomb at ...
Fatal trap 12: page fault while in kernel mode
fault virtual address  = 0x18
...
Stopped at      ffs_fhtovp+0xb: movq    0x18(%rax),%r9     # rax == mnt_data == NULL

Expected (patched kernel): the race survives all rounds; fhstat gets ESTALE during the window instead of a torn-down mount.

Notes

• The panic reproduced on the first driver run (ROUNDS=3, NBOMB=4) within ~35 s — the window is hit easily because every in-window fhstat traps.
• Fix engineering result: a vfs_getvfs() MNTK_UNMOUNT filter ALONE is NOT sufficient — the fix-v1 kernel panicked identically within ~20 s (check-and-use is preemptible). The validated fix (fix.diff) adds the vfs_busy(mp, LK_NOWAIT) interlock (shared mnt_lock excludes the whole dounmount body) to sys_fhstat and nfsrv_fhtovp, keeps the vfs_getvfs filter, and NULL-guards ufs_check_export/ffs_fhtovp. Patched kernel: 6000/6000 rounds survived, zero panics.
• The unprivileged-real-world variant needs nfsd + an exported UFS mount (NFS traffic is unauthenticated); the fh* syscalls used here are root-gated and only demonstrate the kernel-side primitive (same methodology as DF-3236's accepted repro).

DF-3241 VERDICT — ufs_check_export / ufs_fhtovp NULL mnt_data window (dounmount)

Status: REPRODUCED (panic) — fix validated (6000/6000 rounds clean)

What was reproduced

On the stock INVARIANTS kernel (DragonFly 6.5-DEVELOPMENT #0, X86_64_GENERIC), an fhstat(2) that resolves a UFS mount's fsid inside the dounmount() window between VFS_UNMOUNT() (which frees struct ufsmount and clears mp->mnt_data, sys/vfs/ufs/ffs_vfsops.c:862-866) and mountlist_remove(mp) (sys/kern/vfs_syscalls.c:1040) faults deterministically:

Fatal user address access from kernel mode from fhbomb at ffffffff80910b3b
Fatal trap 12: page fault while in kernel mode
fault virtual address  = 0x18
Stopped at      ffs_fhtovp+0xb: movq    0x18(%rax),%r9     ; rax = mnt_data = NULL

0x18 == offsetof(struct ufsmount, um_fs) (ufsmount.h:69-74). Reproduced on the first driver run (ROUNDS=3, NBOMB=4) within ~35 s; the guest sat in DDB (db>).

Why it happens (path:line)

1. sys_fhstat / nfsrv_fhtovp resolve a user/wire fsid with vfs_getvfs() (sys/kern/vfs_mount.c:413-424), which only RB-looks-up the mounttree — it does not check MNTK_UNMOUNT (stock kernel).
2. dounmount() order: dounmount_interlock sets MNTK_UNMOUNT (vfs_syscalls.c:831) → VFS_UNMOUNT frees ump, mnt_data = 0 (vfs_syscalls.c:1006 → ffs_vfsops.c:862-866) → then mountlist_remove (vfs_syscalls.c:1040). Throughout that span the mount is still fsid-resolvable.
3. ffs_fhtovp (ffs_vfsops.c:1216-1218) and ufs_check_export (ufs_vfsops.c:242-246) deref VFSTOUFS(mp) unguarded → NULL read.

Reachability / threat

• PoC path (used here): fhstat(2) — root-gated (same accepted methodology as the DF-3236 devfs twin).
• Real-world unprivileged path: nfsrv_fhtovp() (sys/vfs/nfs/nfs_subs.c: 1235-1246) — unauthenticated NFS traffic to a running nfsd while any exported UFS is force-unmounted; VFS_CHECKEXP → ufs_check_export crashes the same way (NE_LOCK on NULL+0x78 when MNT_EXPORTED sticks, since ffs_unmount never clears it, ffs_vfsops.c:867).
• kern_checkpoint (kern_checkpoint.c:496) has the same shape.

Impact ceiling: kernel NULL-deref panic (DoS) — not a corruption primitive; no escalation chain exists for this bug class (fixed-address read of a zeroed pointer field).

Fix iteration (important engineering result)

• fix v1 — vfs_getvfs() refuses mounts with MNTK_UNMOUNT: INSUFFICIENT. The rebuilt kernel still trapped at ffs_fhtovp+0xb within ~20 s: the check-and-use is a TOCTOU — an fhstat thread can pass the flag check (flag still clear), be preempted at lwkt_reltoken, and a full umount -f completes before the thread loads mnt_data.
• fix v2 (validated) — the airtight interlock is vfs_busy(): it checks MNTK_UNMOUNT under mnt_token AND takes mnt_lock shared, which excludes the entire dounmount body (exclusive mnt_lock from vfs_syscalls.c:842 through 1091, including VFS_UNMOUNT). 1. sys/kern/vfs_mount.c — keep the vfs_getvfs MNTK_UNMOUNT filter (semantics: a dying mount must not be handed out; defense in depth). 2. sys/kern/vfs_syscalls.c sys_fhstat — vfs_busy(mp, LK_NOWAIT) across the VFS_FHTOVP; ESTALE on failure; vfs_unbusy+mount_drop on the way out. 3. sys/vfs/nfs/nfs_subs.c nfsrv_fhtovp — same vfs_busy/unbusy wrap around the CHECKEXP+FHTOVP pair (the unauthenticated threat path). 4. sys/vfs/ufs/ufs_vfsops.c ufs_check_export — NULL mnt_data guard returning EACCES. 5. sys/vfs/ufs/ffs_vfsops.c ffs_fhtovp — NULL mnt_data guard returning ESTALE.

Baseline vs patched, identical driver: * stock kernel: Fatal trap 12 @ 0x18 in ffs_fhtovp ≤ 3 rounds (twice: stock and fix-v1). * fix-v2 kernel (#1 Wed Sep 9 05:56:10): 6000/6000 mount+umount -f rounds with 8 fhstat spinners, SURVIVED, no panic; fhstats return ESTALE during teardown instead of crashing.

Residual notes

• The same fsid-window pattern exists for fhopen/fhstatfs/fhstatvfs (root-gated) and kern_checkpoint; fix v2's vfs_busy pattern should be applied there too (mechanical, same shape). This PoC validated the pattern on sys_fhstat + the NFS path is protected by the same patch.
• ffs_unmount never calls vfs_free_addrlist(&ump->um_export) — radix heads leak on unmount of an exported fs (root-gated; separate low-sev issue, ffs_vfsops.c territory).

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.