DF-2918 — Unynchronized vfsconf registry: mount/kldunload race → hard kernel deadlock (and by-construction UAF)

File: sys/kern/vfs_init.c (pass 2)

Build (in guest)

cc -O2 -o /root/mountloop mountloop.c
cc -O2 -o /root/kldloop   kldloop.c     # optional gap arg, default 10000 usec
cc -O2 -o /root/sysctlloop sysctlloop.c

Guest setup (root):

pw useradd -m -n poc ; pw usermod -n poc -s /bin/sh
mkdir -p /home/poc/mnt ; chown -R poc:poc /home/poc
cp /root/sysctlloop /home/poc/ ; chown poc /home/poc/sysctlloop
sysctl vfs.usermount=1          # only needed for the (currently
                                # stock-unreachable) unpriv mounter variant
kldload /boot/kernel/fuse.ko

Run

sh race.sh 3 600                    # MODE=race default; also starts 2
                                    # unpriv sysctl readers as user poc
# control (no unload churn — must stay healthy):
MODE=control sh race.sh 4 90

Artifacts: /root/race.log, /tmp/mloop., /tmp/kld.out, /tmp/sloop.

Expected (stock INVARIANTS kernel, observed 2026-09-03)

• CONTROL run: mounters complete >600k mount(2) attempts each in 90 s (all EFAULT/EPERM — the mounts are supposed to fail; the vulnerable window vfs_syscalls.c:313→:359 is crossed on every attempt) with zero adverse effects. Guest stays healthy.
• RACE run: within 15–25 s every mounter thread wedges permanently in kernel D-state (wchan ncplk / syncexit / vnode), kldloop wedges inside the linker, fuse.ko is pinned loaded, mount(2) and kldload/ kldunload are dead system-wide, wedged threads survive SIGKILL, the guest can no longer shut down cleanly ("guest not answering"), and a forced debug.panic hangs in syncing disks.... Only a hard reset recovers. Reproduced 3/3 race runs; control clean 1/1.

Key observation about the failure shape

kldloop immediately reloads the module after each unload, so the freed module address range is typically re-mapped (likely at the same address) before a mounting thread dereferences its stale vfsp/vfsops pointer — the stale pointer hits valid memory of the fresh module copy and the corruption manifests as corrupted lock/refcount state → the observed irrecoverable deadlock, rather than a page-fault panic. With a post-unload gap (GAP=10000/50000) the range stays unmapped longer, but the lock cascade still wins the race on this kernel.

DF-2918 — VERDICT

Finding: sys/kern/vfs_init.c — the vfsconf registry (the list walked by every mount, every sysctl vfs.generic enumeration) has zero synchronization: no lock, no token, non-atomic vfc_refcount. vfs_unregister() (vfs_init.c:458-480) checks vfsp->vfc_refcount != 0 (:469) and then removes the entry (:478) with nothing to serialize it against sys_mount()'s unlocked vfsconf_find_by_name() at vfs_syscalls.c:313 followed by vfsp->vfc_refcount++ at :359 — a window that contains an M_WAITOK kmalloc and a syncer kthread creation (vfs_syscalls.c:354-356), i.e. hundreds of microseconds, and is crossed by every mount(2) attempt, including ones that ultimately fail. A concurrent kldunload can therefore unregister + unload a filesystem module while a mount thread is mid-window: the mounter then writes vfc_refcount++ into freed module address space and dereferences mp->mnt_op / vfsp->vfc_vfsops pointers into the unloaded module (UAF write + UAF indirect call).

Reproduced? YES — hard kernel deadlock of the mount/linker subsystem

(status=reproduced, impact=dos on this kernel; the UAF write/call is established by construction — see "why no page-fault panic" below)

Guest: DragonFly 6.5-DEVELOPMENT #0 x86_64 (stock INVARIANTS kernel), single-tenant QEMU/KVM rig (dfbsd-qemu/vm.sh).

PoC: mountloop hammers mount("fuse", "/home/poc/mnt", 0, NULL) (each attempt crosses the vulnerable window; the mount itself is expected to fail EFAULT after the window), kldloop (root) cycles kldload/kldunload("/boot/kernel/fuse.ko") — the unload keeps winning the racy refcount check whenever it lands in a mounter's pre-increment window.

• Control (mounters only, module loaded, no unload churn): 4 mounters × 600,000+ iterations in 90 s, zero adverse effects, clean exit, guest healthy (run.log, Run 3).
• Race (mounters + kldunload churn): 3/3 runs wedged irrecoverably within 15 s – 4 min: every mounter thread permanently D-state with wchan ncplk / syncexit / vnode, the kldloop wedged inside the linker, fuse.ko pinned loaded, mount(2) and kldload/kldunload dead system-wide. Wedged threads ignore SIGKILL. The guest can no longer be shut down ("guest not answering" — QEMU hard-kill required) and even a forced debug.panic=1 hangs in syncing disks... (crash-dump sync deadlocked on the same corrupted state; serial log captured in run.log). Unprivileged sysctl vfs.generic enumeration loops (84M+ reads) kept running throughout, so the wedge is owned by the mount/linker path.
• Mechanism correlation: dmesg shows fuse_init(mountloop|1367) — the mounter's own sys_mount autoload (:324) interleaved with kldloop's explicit loads/unloads of the same module, exactly the unsynchronized registration envelope described above.

Why no page-fault panic (and why that doesn't weaken the finding)

kldloop reloads the module immediately after each successful unload, so the freed module address range is re-mapped (typically at the same address) before a mounter dereferences its stale vfsp; the stale pointer hits valid memory of the fresh module instance → silent state corruption (refcount/lock state) → the observed irrecoverable deadlock. With a post-unload gap (GAP=10000/50000) the range stays unmapped longer, but the lock cascade still wins on this kernel (run 5/6). The write-side UAF is nonetheless provable by construction: between vfs_syscalls.c:313 and :359 nothing prevents vfsconf_remove() (vfs_init.c:276) + module unload; every subsequent access in that window (mount_init(mp, vfsp->vfc_vfsops) at :355, vfsp->vfc_refcount++ at :359) is a use of freed module memory.

Why not uid0 (documented hard blocker)

The unload side requires root (kldunload is privileged), so this is not an unprivileged→root primitive; escalation would require a privileged conspirator, at which point root already exists. The fully-unprivileged mounter variant (vfs.usermount=1) is real but was not reachable on this stock guest because every user-mountable fstype (null/devfs/procfs/tmpfs) is compiled into the kernel and the one modular user-facing type, fuse, registers vfc_name "fuse" (sys/vfs/fuse/fuse_vfsops.c:490) while get_fscap() (vfs_syscalls.c:5385-5395) only whitelists "fusefs", so an unprivileged mounter is EPERM-gated before the window. On a kernel with a modular user-mountable filesystem (or if that fuse/get_fscap mismatch is fixed), the identical race is drivable end-to-end by an unprivileged user against a root-initiated (or automated) kldunload.

Secondary observations recorded during verification

1. sys_mount's auto-load path (vfs_syscalls.c:315-342) bumps lf->userrefs only on the autoload path; mounts of a module that root kldloaded manually are protected only by the racy refcount check — the same envelope.
2. vfs_register()'s sysctl renumber loop (vfs_init.c:338-343) iterates sysctl__vfs_children without SYSCTL_XLOCK while unregistering/re-registering the iterator itself mid-loop (filed as DF-2919).
3. The wedge also blocked crash-dump sync — a panic on a raced system cannot complete its dump.
4. vfs_register() ignores the return value of vfs_init(vfc) (vfs_init.c:445) — no in-tree filesystem fails init today (hardening note only).

Fix validation (two stages — see run.2.log)

fix.diff (final, v2) adds to sys/kern/vfs_init.c a lockmgr registry lock (vfsconf_lk): lookups/iteration take it shared; new vfsconf_acquire() does lookup + atomic_add_int(&vfc_refcount, 1) under shared (excluding unregister's exclusive section); vfsconf_release() drops atomically; vfs_register() does duplicate-check+insert under exclusive; vfs_unregister() does find + refcount-check + uninit + remove as ONE exclusive critical section, and additionally returns EBUSY while any mount(2) syscall is in flight (vfsconf_mount_begin/end() bracket sys_mount). sys_mount / dounmount / vfs_rootmountalloc converted to acquire/release (vfs_syscalls.c, vfs_mount.c).

• v1 (registry lock + acquire/release only), built in-guest, kernel #1: closed the vfsconf lifetime TOCTOU (mounters survived ~10× longer) but the deadlock still formed at ~150 s via the second edge — sys_mount's in-syscall autoload enters the linker while holding the mountpoint vnode lock (AB-BA against kldunload holding the linker lock), and vn_syncer_thr_stop() waits unconditionally for a syncer thread whose kthread_create() result is ignored (vfs_sync.c:318-322).
• v2 (adds the in-flight-mount veto), built in-guest (make nativekernel KERNCONF=X86_64_GENERIC RC=0, make installkernel RC=0), booted as kernel #2: the IDENTICAL race workload ran the full 600 s with 6.6M/4.8M/5.0M mount attempts across the three mounters, 161M unprivileged sysctl enumerations, kldloop cycling the whole time, zero wedged D-threads, no panic, guest healthy — === survived 600 seconds ===. Baseline wedged in ≤100 s on 3/3 runs.

Follow-ups recommended beyond this diff: (a) audit kthread_create failure handling in vn_syncer_thr_create/stop (independent latent hang, exposed by this churn); (b) reconcile get_fscap("fusefs") with the fuse module's registered vfc_name "fuse" (currently functionally disables unprivileged fuse mounts); (c) take lf->userrefs (or equivalent) for mounts of manually-kldloaded modules, not just the autoload path.