DF-3073 — nfs_unmount frees the nfsmount after a failed forced vflush (busy device vnode) → use-after-free + deterministic "unmount: dangling vnode" panic

What

sys/vfs/nfs/nfs_vfsops.c:nfs_unmount() (lines 1217-1224): when vflush(mp, 1, flags) fails, NFS continues tearing down the mount anyway if MNT_FORCE was requested ("If this doesn't work and we are doing a forced unmount we continue anyway"). But vflush() can legitimately fail even with FORCECLOSE: vflush_scan() (sys/kern/vfs_mount.c:1145-1146) clears FORCECLOSE for VCHR/VBLK vnodes and counts them busy (:1194), returning EBUSY whenever a device vnode on the mount still has VREFCNT>1.

Continuing anyway means:

1. nfssvc_iod_stop1/2, nfs_disconnect, removal from nfs_mountq, then nfs_free_mount(nmp) (nfs_vfsops.c:1232-1243) — which does kmalloc_destroy_obj(&nmp->nm_mnode) and kfree(nmp, M_NFS) while the surviving device vnode and its nfsnode are still alive (nfs_free_mount, nfs_vfsops.c:1248-1262; allocator warning "NFS inodes: … 1 objects were still allocated" on the INVARIANTS kernel). From this point any touch of that vnode (nfs_inactive → lwkt_gettoken(&nmp->nm_token) at sys/vfs/nfs/nfs_node.c:383-387; nfs_reclaim → kfree_obj(np, nmp->nm_mnode) at nfs_node.c:439,485) is a use-after-free on the freed nmp and on a destroyed malloc type (kmalloc_destroy frees the struct malloc_type itself, sys/kern/kern_slaballoc.c:624-631).
2. dounmount() then panics unconditionally because the vnode is still on mp->mnt_nvnodelist: panic("unmount: dangling vnode") (sys/kern/vfs_syscalls.c:1085-1086) — observed as dounmount+0x87c.

Threat model

• The device vnode itself comes from the NFS server (LOOKUP/GETATTR attributes type=NF3CHR with a chosen rdev — the DF-2998 server-side-retyping surface), or from a device node root created on the export. A hostile/compromised server controls this fully.
• Any unprivileged local user can hold the device vnode referenced in a way no unmount cleanup can break: open the node, then park the fd in a unix-socket SCM_RIGHTS receive buffer (holder2.c). The fd then belongs to no process, so dounmount()'s kill-retry loop (unmount_allproc_cb/process_uses_mount, SIGINT retry 3 / SIGKILL retry 7, vfs_syscalls.c:768-947) matches nobody; the namecache ref and vnode ref persist indefinitely.
• Root's routine umount -f of a (e.g. stale) NFS mount then takes the machine down, after having freed the mount's kernel state out from under a live vnode.

Files

• fakesrv2.c — loopback fake rpcbind/mountd/NFSv3 server (TCP): serves a root dir with dev (VCHR, rdev 14:2 = /dev/null on the stock guest) and slow (VREG). holder.c (NFS-blocked variant) is kept for history; holder2.c (SCM_RIGHTS variant) is the one that works — nfs_sigintr() aborts every in-flight RPC the moment MNTK_UNMOUNTF is set (nfs_socket.c:2059-2066), so an NFS-blocked process is always released by umount -f.
• build.sh / run.sh — compile and three-phase run (control, EBUSY, panic).

Build

sh build.sh        # cc -O2 -o fakesrv2 fakesrv2.c; cc -O2 -o holder2 holder2.c

Run (as root on the guest)

sh run.sh
# phase A: umount -f with no holder   -> clean (control)
# phase B: holder2 + umount           -> "Device busy" (control)
# phase C: umount -f                  -> ~13s retry loop, then panic:
#   unmount(/mnt/nfsx): ... N namecache refs, N mount refs still present
#   vflush: Warning, cannot destroy busy device vnode
#   NFS inodes: slab ... 1 objects were still allocated
#   malloc_uninit: 576 bytes of 'NFS inodes' still allocated on cpu 6
#   panic: unmount: dangling vnode
#   dounmount() at dounmount+0x87c
# (ssh session dies; capture is on the serial console / vm.sh log)

Expected outcome

Stock kernel: deterministic kernel panic (panic.txt). Patched kernel (fix.diff): phase C prints C_UMOUNT_FORCE_RC=1 (EBUSY), the guest stays up, the mount stays usable, and after the holder releases (kill holder2) umount -f succeeds normally.

DF-3073 VERDICT — nfs_unmount: use-after-free + deterministic panic after failed forced vflush

Bottom line

REPRODUCED (impact: panic — deterministic local kernel DoS with a proven kernel use-after-free window immediately before the panic). On the stock INVARIANTS kernel, umount -f of an NFS mount while a referenced device vnode lives on the mount (held open by an unprivileged user via an SCM_RIGHTS-parked descriptor, device node supplied by the NFS server) makes nfs_unmount() free the nfsmount and destroy the nfsnode objcache with the device vnode's nfsnode still allocated, after which dounmount() panics unconditionally. The allocator's own NFS inodes: ... 1 objects were still allocated warning on the console is direct evidence of the lifetime violation; without INVARIANTS the same sequence silently leaves a freed nmp behind a live vnode (nfs_inactive/nfs_reclaim would then operate on freed memory: sys/vfs/nfs/nfs_node.c:383-387 and :439,485), but the panic("unmount: dangling vnode") at sys/kern/vfs_syscalls.c:1085-1086 fires microseconds later in the same syscall, so the realistic ceiling on this path is a reliable panic rather than a controllable corruption.

Root cause chain (all source-cited, all observed on the guest)

1. dounmount() sets MNTK_UNMOUNTF and runs a 50×250ms kill-retry loop (vfs_syscalls.c:839-972) that SIGINTs (retry 3) / SIGKILLs (retry 7) every process matching process_uses_mount() (:727-757). A descriptor parked in a unix-socket receive buffer belongs to no process, so nobody is killed; its f_nchandle keeps a namecache ref and a mount ref ("1 namecache refs, 1 mount refs still present" on the console).
2. VFS_UNMOUNT → nfs_unmount() → vflush(mp, 1, FORCECLOSE). vflush_scan() clears FORCECLOSE for VCHR/VBLK vnodes (sys/kern/vfs_mount.c:1145-1146) and counts them busy (:1194) when VREFCNT>1 — the parked fp's vnode ref + the surviving ncp's ref give exactly that. Console: vflush: Warning, cannot destroy busy device vnode; vflush returns EBUSY.
3. nfs_unmount() ignores the failure because FORCECLOSE was requested (sys/vfs/nfs/nfs_vfsops.c:1218-1224 "forced unmount we continue anyway") and completes the teardown: nfssvc_iod_stop1/2, nfs_disconnect, removal from nfs_mountq, then nfs_free_mount(nmp) (:1232-1243) → kmalloc_destroy_obj(&nmp->nm_mnode) + kfree(nmp, M_NFS) (:1248-1262). The still-referenced device vnode keeps its nfsnode (allocated from that objcache) and its v_mount->mnt_data == freed nmp. Console: NFS inodes: slab ... 1 objects were still allocated + malloc_uninit: 576 bytes of 'NFS inodes' still allocated on cpu 6.
4. Back in dounmount(): panic("unmount: dangling vnode") (vfs_syscalls.c:1085-1086) because the vnode never left mp->mnt_nvnodelist. Backtrace: dounmount+0x87c ← sys_unmount.

Why the holder must not be NFS-blocked (design detail)

First attempt (holder.c) blocked the holder inside a withheld READ RPC on a hard mount. That fails: nfs_sigintr() returns EINTR for every request as soon as MNTK_UNMOUNTF is set (sys/vfs/nfs/nfs_socket.c:2059-2066), the blocked process becomes killable, retry-7 SIGKILL closes its fds, namecache refs drop, vflush succeeds and umount -f returns 0 in ~2s (observed, run.log session 2). The SCM_RIGHTS variant (holder2.c) holds no NFS state at all — only the socket — and survives the entire kill-retry loop (12.5s, observed).

Reproduction

Baseline (stock kernel #0 Thu Jul 2 06:02:54 UTC 2026): see run.sh / run.log / panic.txt. Deterministic across the run (single decisive run after two control runs; the panic path is unconditional once vflush fails — no race involved).

Controls observed on the same setup: - umount -f with no holder: clean unmount (RC=0). - umount (no force) with holder: clean EBUSY, mount intact. - umount -f with NFS-blocked holder: holder killed, clean unmount (MNTK_UNMOUNTF aborts its RPC) — demonstrates the abort-everything semantics that the SCM_RIGHTS variant sidesteps.

Exploitability assessment (honest)

• Deterministic: kernel panic, any user who can get a device-node fd parked on an NFS mount + a root umount -f.
• The UAF window (freed nmp behind a live vnode) provably exists (the allocator reports the leaked-live object at destroy time), but the unconditional dounmount panic fires within the same syscall, in-line, before any other thread can act on the vnode (the vnode is VX-unlocked after the vflush scan, yet the panic check runs with only journal_remove_all_journals/mountlist_remove/vfs_rm_vnodeops in between). On this guest (UP-class INVARIANTS kernel) there is no realistic window to convert the free into controlled corruption before the panic; on an SMP box the theoretical window is the same few function calls. I therefore classify impact as panic (local DoS), not privesc.
• Severity context: the unprivileged user only primes the state; the final trigger is root's umount -f — the documented remedy for a stale NFS mount, i.e. an action an admin is more likely to take when a hostile server is involved.

Fix validation

fix.diff (in this pack): nfs_unmount() returns the vflush error unconditionally and clears NFSMNT_FORCE on that path (the flag would otherwise permanently wedge the still-mounted filesystem — nfs_socket.c:200,1288).

Patched kernel (built in-guest: make nativekernel KERNCONF=X86_64_GENERIC after applying fix.diff to /usr/src): the exact PoC rerun yields umount -f → EBUSY, no panic, guest stays up, mount intact; after the holder releases the parked descriptor, umount -f succeeds normally. Baseline panic vs patched EBUSY captured in run.fixed.log / fixed.console.txt.

Environment

See env.txt (guest uname, compiler, sysctls, listeners).