DF-0044 run.log -- decisive 60-second unprivileged stress run.
Guest: DragonFly dfbsd 6.5-DEVELOPMENT v6.5.0.1712.g89e6a-DEVELOPMENT
       X86_64_GENERIC, built 2026-06-29 (master DEV).
Setup: sysctl vfs.usermount=1 (root), then as maxx (uid 1001):
       initial tmpfs mounted at /tmp/df0044/m; binary hosted inside it;
       cycler threads mount+unmount the path while reader threads read
       /proc/self/map (driving vn_fullpath guess=1 -> cache_fullpath ->
       mount_get_by_nc -> deref of new_mp->mnt_ncmounton).

Command:    cd /tmp/df0044/m && ./mount_uaf /tmp/df0044/m 60 2
Exit code:  0

================================================================================
$ cd /tmp/df0044/m && ./mount_uaf /tmp/df0044/m 60 2
DF-0044: cycling mount at /tmp/df0044/m (uid=1001 gid=1001)
DF-0044: 2 cycler threads + 4 /proc/self/map readers
DF-0044: running 60 seconds
DF-0044: deref=288137  free_ok=2  free_fail=6
DF-0044: still alive -- race not won this run
================================================================================

Interpretation:
  * 288,137 deref-side /proc/self/map reads (each invokes vn_fullpath with
    guess=1 on the binary's text vp whose path traverses the cycled
    mountpoint, exercising cache_fullpath -> mount_get_by_nc -> deref).
  * Only 2 successful free-side cycles in 60s: most mount attempts fail with
    EPERM/EBUSY because the path is overmounted by a peer thread; once a
    cycle succeeds, the kfree is gated by an mnt_refs drain that takes many
    milliseconds, while the deref at vfs_cache.c:5224 finishes in nanoseconds.
  * No kernel panic, no slab complaints, no fatal trap.  The guest stayed up.

Companion boot.log excerpt (panic.txt) shows the kernel detecting the
concurrent unmounts and printing "nlookup: warning umount race avoided"
(vfs_nlookup.c:1056) and "unmount ... forcing unmount" (vfs_syscalls.c:988),
but never crashing.  The kernel's nlookup and dounmount retry logic catch
most concurrent access and either bail out (returning EBUSY) or proceed
without freeing (freeok=0), so the actual UAF (read of freed-then-reallocated
mp memory) does not occur in this run.