DF-0044 — PoC

mount_uaf.c — race between path-resolution across a mountpoint and unmount of that mountpoint, intended to trigger the UAF in cache_fullpath via mount_get_by_nc's unheld return.

mount_uaf_root.c — root-only variant that uses MNT_FORCE for a faster free-side cycle (used during verification; not the unprivileged vector).

The bug (code-level confirmed on master DEV)

mount_get_by_nc (sys/kern/vfs_mount.c:1235-1248) returns mp without mount_hold (token released :1245, return :1247), unlike its sibling vfs_getvfs (:413-424, which mount_holds at :420-421 and documents the hold contract in the comment at :410-411). mountlist_scan (:756, :784) also mount_holds before dropping mountlist_token. Thus mount_get_by_nc is the lone outlier and breaks the file's own invariant.

The sole caller, cache_fullpath (sys/kern/vfs_cache.c:5214), dereferences new_mp->mnt_ncmounton (:5224) after the token has been released and never calls mount_drop(new_mp). A concurrent dounmount (sys/kern/vfs_syscalls.c:1040 removes from mountlist, :1066-1069 zeroes mnt_ncmounton, :1108-1117 waits for mnt_refs==0 then mount_drop→kfree) frees mp → use-after-free on the deref at :5224.

Reachability

• Deref side: the ONLY caller of cache_fullpath(guess=1) is sys/vfs/procfs/procfs_map.c:181 (vn_fullpath(p, vp, ..., 1) when reading /proc/$pid/map). So the deref is driven by reading /proc/$pid/map for a vnode whose path traverses a mountpoint. Most other cache_fullpath callers (__getcwd, kern.proc.pathname, kern.proc.cwd, kern_proc_filedesc, kern_exec, etc.) use guess=0 and do not invoke mount_get_by_nc.
• Free side: unmount. With vfs.usermount=1 an unprivileged user owns a mount they created and drives both sides (mount+umount their own FS); otherwise the free side races a privileged unmount (automounter / removable media / privileged daemon).

Build & run (unprivileged with vfs.usermount=1; disposable VM)

# as root: enable user mounts and prepare a directory maxx owns
sysctl vfs.usermount=1
mkdir -p /tmp/df0044/m && chown maxx:maxx /tmp/df0044/m && chmod 0755 /tmp/df0044/m

# as maxx: build the PoC, host it inside the mount, and run it from there
cc -pthread -O2 -o mount_uaf mount_uaf.c
mount -t tmpfs dummy /tmp/df0044/m   # initial mount to host the binary
chmod 0755 /tmp/df0044/m
cp mount_uaf /tmp/df0044/m/
cd /tmp/df0044/m && ./mount_uaf /tmp/df0044/m 60

The PoC pins a tmpfs over its own CWD (so /proc/self/map's text-vp path traverses the cycled mountpoint), then has cycler threads mount+unmount the path (free side) while reader threads repeatedly open and read /proc/self/map (deref side).

Expected output (bug present)

A kernel panic in _cache_hold on a bogus ncp pointer, or a slab/UAF signature, when the race is won. Realistically the race is extremely tight on a non-INVARIANTS kernel — see VERDICT.md.

DF-0044 — VERDICT

Verdict: NOT REPRODUCED (race too tight to win on the non-INVARIANTS master kernel) — but the code-level bug is CONFIRMED.

The missing mount_hold in mount_get_by_nc is real and present on master DEV (X86_64_GENERIC, v6.5.0.1712.g89e6a-DEVELOPMENT, built 2026-06-29). A multi-minute, multi-strategy stress campaign could not produce a kernel panic, but the code-level proof below shows the UAF exists, and the fix is warranted as defense-in-depth (the function violates the file's own documented invariant and is the lone outlier among its siblings).

Code-level proof (every line cited from the audited sys/ tree)

1. mount_get_by_nc returns mp without a hold

sys/kern/vfs_mount.c:1235-1248:

struct mount *
mount_get_by_nc(struct namecache *ncp)
{
        struct mount *mp = NULL;

        lwkt_gettoken_shared(&mountlist_token);            /* :1240 */
        TAILQ_FOREACH(mp, &mountlist, mnt_list) {
                if (ncp == mp->mnt_ncmountpt.ncp)
                        break;
        }
        lwkt_reltoken(&mountlist_token);                    /* :1245  mp not held */
        return (mp);                                       /* :1247  unheld pointer */
}

mount_hold(mp) is never called. Contrast the otherwise-identical vfs_getvfs (:413-424), whose comment at :410-411 states the contract ("the returned mp is held and the caller is expected to drop it via mount_drop()") and which executes if (mp) mount_hold(mp); at :420-421 before releasing the token at :422:

struct mount *
vfs_getvfs(fsid_t *fsid)
{
        struct mount *mp;

        lwkt_gettoken_shared(&mountlist_token);             /* :418 */
        mp = mount_rb_tree_RB_LOOKUP_FSID(&mounttree, fsid);
        if (mp)
                mount_hold(mp);                             /* :420-421 */
        lwkt_reltoken(&mountlist_token);                    /* :422 */
        return (mp);
}

mountlist_scan (:756, :784) also mount_holds each mount before dropping the token across its callback. mount_get_by_nc is the only function in the file that drops the token while still holding an unprotected mp pointer. The hold is what prevents dounmount's final kfree(mp, M_MOUNT) (see sys/kern/vfs_mount.c:393-405) from freeing the struct while a caller is still inside the dereference window.

2. The sole caller derefs the unheld mp after the token is dropped

sys/kern/vfs_cache.c:5213-5230:

if (guess && (ncp->nc_flag & NCF_ISMOUNTPT)) {
        new_mp = mount_get_by_nc(ncp);                      /* :5214 -- unheld */
}
if (ncp == mp->mnt_ncmountpt.ncp) {
        new_mp = mp;
}
if (new_mp) {
        nch = new_mp->mnt_ncmounton;                        /* :5224 -- DEREF */
        _cache_drop(ncp);
        ncp = nch.ncp;
        if (ncp)
                _cache_hold(ncp);
        mp = nch.mount;
        continue;
}

The function returns to cache_fullpath with the mountlist_token already released (:1245) and new_mp is dereferenced at :5224 to copy mnt_ncmounton. No mount_hold was taken on new_mp and no mount_drop exists in the caller. The hold on the ncp (_cache_hold(ncp) at :5228) pins the namecache node but not the mount struct.

3. dounmount frees mp after the token has been released

sys/kern/vfs_syscalls.c:

mountlist_remove(mp);                       /* :1040 -- removes from mountlist */
...
if (mp->mnt_ncmounton.ncp != NULL) {        /* :1066 */
        nch = mp->mnt_ncmounton;
        cache_zero(&mp->mnt_ncmounton);     /* :1069 -- zeroes mnt_ncmounton */
        cache_clrmountpt(&nch);
        cache_drop(&nch);
}
...
while (mp->mnt_refs > 0) {                  /* :1110 -- drain refs (may tsleep) */
        cache_unmounting(mp);
        wakeup(mp);
        tsleep(&mp->mnt_refs, 0, "umntrwait", hz / 10 + 1);
        cache_clearmntcache(mp);
}
lwkt_reltoken(&mp->mnt_token);
mount_drop(mp);                             /* :1117 -- kfree(mp, M_MOUNT) */

The kfree at the end (via mount_drop at sys/kern/vfs_mount.c:399-405) frees the very struct the unheld pointer in cache_fullpath may still be about to dereference at :5224. This is the UAF.

Why it is hard to demonstrate as a panic

For the UAF to manifest as observable corruption or a panic, three things must all happen in a window of microseconds:

1. mount_get_by_nc returns mp while the unmount is past mountlist_remove AND past the mnt_refs==0 drain AND past mount_drop→kfree.
2. The slab memory has been reallocated and overwritten with attacker- controlled or garbage data (otherwise the freed memory still reads as zeroed mnt_ncmounton from the cache_zero at :1069, and the if (ncp) check at :5227 makes the loop exit cleanly — no crash).
3. The freed/reallocated mnt_ncmounton.ncp is a non-NULL garbage pointer that _cache_hold then dereferences.

On a non-INVARIANTS X86_64_GENERIC kernel the deref at :5224 is a single (register-width) memory read and finishes in nanoseconds; the unmount's kfree is gated by a tsleep-bounded mnt_refs==0 drain that typically takes milliseconds. In practice the deref almost always reads the zeroed-but-still-mapped mnt_ncmounton ({NULL, NULL}) and the loop exits benignly. Additionally the kernel's nlookup path (sys/kern/vfs_nlookup.c:1056) prints nlookup: warning umount race avoided and bails out on MNTK_UNMOUNT-flagged mounts, which competes away some of the racing lookups.

Verification campaign (all on the booted master DEV guest)

vfs.usermount=1 was enabled as root; the unprivileged maxx user owns the mounts and drives both sides. Three strategies were attempted:

1. Unprivileged variant (mount_uaf.c) — binary hosted inside a tmpfs overmounted+unmounted by cycler threads while reader threads read /proc/self/map. 60-second run: 288,137 deref-side vn_fullpath iterations, 2 successful free-side cycles (over-mount+unmount), 6 failed. No panic. (run.log)
2. Root variant (mount_uaf_root.c) — same race, root only, with MNT_FORCE for faster free-side teardown. Defeated by sys/kern/vfs_syscalls.c:931-947: MNT_FORCE calls allproc_scan(unmount_allproc_cb) which SIGINT/SIGKILLs processes whose p_textnch / CWD / open fds are on the mount, killing the test process itself.
3. Inspecting boot.log for the panic signature across all runs — only unmount ... forcing unmount and nlookup: warning umount race avoided messages appear; no fatal trap, panic:, or Stopped at. (boot.log excerpt in panic.txt — empty.)

Verdict classification

The realistic outcome of the missing hold is:

• Most of the time: the deref at :5224 reads zeroed mnt_ncmounton and the loop exits benignly (no crash, no corruption).
• Occasionally: the deref reads stale-but-still-valid mnt_ncmounton from the freed-but-not-yet-reallocated slab (also benign).
• Rarely: if heap grooming forces the slab to be reallocated with attacker data between kfree and the read, the deref hands a garbage ncp to _cache_hold, which crashes (DoS) or leaks recycled slab memory (info disclosure). This is the theoretical worst case but I could not trigger it on this kernel.

So: the bug is real and the fix is warranted (it removes a clear invariant violation and eliminates a genuine, if narrow, UAF window), but on this kernel it could not be turned into an observable panic within a reasonable time budget, even with significant hammering. An INVARIANTS build (with DEBUG=-g slab poisoning / M_USE_WAIT / KKASSERT on mnt_refs) would likely turn this into a reliable panic.

Recommended fix

fix.diff adds mount_hold(mp) in mount_get_by_nc (matching vfs_getvfs) and the matching mount_drop(new_mp) in the cache_fullpath caller. The fix matches the proposal in findings/DF-0044-mount-get-by-nc-unheld-uaf-cache-fullpath.md, with the additional caller-side mount_drop (which the finding markdown mentions but does not show as a diff).