DF-3117 — racing create vs cross-parent msdosfs directory rename wedges the system

What

Two unprivileged processes on any writable msdosfs directory:

• R: cross-parent directory renames (bouncer: mkdir D in p1, rename into a deep parent p2 — every rename runs doscheckpath() with the target directory unlocked), and
• C: a create/stat/unlink churn loop (creator)

race for 30–60 s. All racer processes exit cleanly, but afterwards:

1. umount of the filesystem hangs forever (leaked mount/vnode references — the earlier console diagnostic printed unmount(/fatrace): ... 2 mount refs still present), and
2. the guest then goes catatonic: sshd stops accepting connections ("Connection timed out during banner exchange"), the serial console freezes, and vm.sh status reports down while the QEMU process is still alive. No panic, no DDB — a hard system wedge.

Reproduced twice (run.9 and the attribution-clean run.10), on a fresh vm.sh reset with-src guest with a fresh image and verified-zero leftover processes before the umount.

Control: the Window-B configuration (file renames only, no doscheckpath) unmounts instantly after identical churn (run.3.log / run.5.log stage [6]) — isolating the trigger to the directory-rename/doscheckpath path.

Where (kernel_refs)

The leak site is not line-pinned (needs VFS refcount instrumentation); the racing surface spans:

• sys/vfs/msdosfs/msdosfs_vnops.c:916-1294 — msdosfs_rename state machine (vref/vput/vrele protocol across the doscheckpath + relookup unlock windows, kern_rename EAGAIN retry interplay)
• sys/vfs/msdosfs/msdosfs_lookup.c:792-872 — doscheckpath's deget/vput ancestor walk (brelse/deget error contract verified clean sequentially; suspect under interleaving)
• sys/kern/vfs_syscalls.c:4316-4332 — kern_rename: retry due to race EAGAIN path (logged live during the race)
• sys/kern/vfs_default.c:953-1069 — vop_compat_nrename

PoC

Same harness as DF-3116 (trigger.c, wedge.sh). The decisive run is run.10.wedge.log: racers done + "leftover procs: none" + umount watchdog never completing + ssh channel death.

No fix.diff: a correct fix requires pinpointing the leaking statement (upstream should reproduce under a VFS_REFCOUNT/debug-refcount kernel build). Recommended containment while unfixed: none realistic; severity is availability of the whole system, triggered by any local user with write access to one msdosfs directory.

DF-3117 VERDICT — racing create vs cross-parent dir rename: mount-ref leak → umount hang → system wedge

Status: REPRODUCED (impact=dos). Twice; the decisive run is attribution-clean.

How it reproduces

1. Fresh vm.sh reset with-src guest (stock INVARIANTS kernel #0, 6 vCPU), fresh 512 MB FAT32 image on /dev/vn0, mounted -u 65534 -g 65534 -m 0777 at /fatrace.
2. p1 = /fatrace/p1 (shallow); p2 = /fatrace/deep/l1/../l100 (a 100-deep chain, so every doscheckpath() walk is ~100 hops).
3. Three unprivileged (nobody) racers for 30 s: - bouncer: 38,661 cross-parent directory renames (mkdir D in p1, rename into p2) — all succeeded (0 errors), - creator in p2: 58,608 create+verify+rotate cycles — 0 vanished, - creator in p1: 41,422 cycles — 0 vanished.
4. All racers exit; ps confirms zero leftover processes ("leftover procs: none").
5. umount /fatrace under a 20 s watchdog never completes; the ssh channel then dies ("Connection timed out during banner exchange"), the serial console freezes (no further output, no panic, no DDB), and vm.sh status reports down while the QEMU process stays alive. See run.10.wedge.log (cut off mid-umount by the wedge itself) and run.9.log for the first occurrence.

First occurrence (run.9, same race shape, 60 s): identical — umount stage hung silently, guest later went unresponsive; the console from that session additionally showed the kernel diagnostic unmount(/fatrace): ... 2 mount refs still present (from a subsequent forced umount attempt), i.e. two leaked mount references, and kern_rename: retry due to race on: "D68634" -> "D68634" (12,0) (sys/kern/vfs_syscalls.c:4323), proving the rename race machinery was live during the churn.

Control (isolates the trigger)

The Window-B configuration — identical creator churn against same-dir file renames (no directory renames, hence no doscheckpath) — unmounts instantly and fsck's clean (run.3.log / run.5.log stage [6]). The wedge therefore requires the cross-parent directory rename path (msdosfs_rename's doscheckpath/relookup unlock windows + deget/vput ancestor walk), racing ordinary creates.

Root cause status

The leaking statement is not line-pinned. Sequentially, the ref protocol in msdosfs_rename/doscheckpath/vop_compat_nrename is balanced on every path I hand-traced (including doscheckpath's brelse/deget error contract — deget clears *depp on all error returns, msdosfs_denode.c:291,318,374). The leak therefore manifests only under a specific interleaving (candidates: the vref(tdvp)+doscheckpath vput pairing under kern_rename EAGAIN retry, the relookup-found-tvp combinations at vnops:1056-1102, or deget's error-path denode left hash-resident at msdosfs_denode.c:363-376). Pinning it requires a VFS refcount-debug kernel build; recommended first step upstream.

Impact

Any local user with write access to a single directory on any mounted msdosfs filesystem (USB stick, FAT partition, user-mounted image with vfs.usermount=1) can, in ~30 s of unprivileged racing, leak mount references such that the filesystem can never be unmounted and the system subsequently wedges entirely (no panic, no dump — hard catatonia). Availability-only; confidentiality/integrity untouched by this aspect (the integrity consequence of the same racing surface is DF-3116).

Fix

No fix.diff — no line-pinned root cause. Upstream should reproduce under refcount instrumentation (e.g. DEBUG_VFS_LOCKS / VFS_REFCOUNT equivalents) on the bouncer+creator workload in wedge.sh; prime suspects listed above. fix_status=not_testable for the same reason.

Guest state

The wedge dirtied the guest twice; vm.sh reset with-src was run afterward and the guest is up and clean (source tree verified restored, no leftover artifacts beyond /tmp copies removed by the reset).

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.

(No fix.diff for this item: documented recommendation only - see Fix above.)