DF-2774 — stale vp->v_pfsmp used via mountlist_exists() after nullfs unmount

What this proves

_cache_setvp() (sys/kern/vfs_cache.c:1386-1389) stores a raw, unheld, never-cleared pointer vp->v_pfsmp = mp into the lower filesystem's vnode whenever that vnode is resolved through a nullfs mount.

vq_vptomp() (sys/kern/vfs_quota.c:421-433) dereferences that stale pointer after "validating" it with mountlist_exists() (sys/kern/vfs_mount.c:692-708), which only does a pointer comparison walk of the mountlist under the shared mountlist token — it takes no reference and provides no lifetime guarantee (the source FIXME at vfs_mount.c:689-691 admits this).

Consequences: 1. After the nullfs mount is unmounted and its struct mount is kfree'd, a fresh mount that reuses the same kfree'd chunk makes mountlist_exists(stale) return 1 (the new, unrelated mount is on the list at the same address). 2. vq_vptomp() then returns the stale pointer, and VFS accounting (VFS_ACCOUNT at sys/kern/vfs_vnops.c:325, vq_write_ok at sys/kern/vfs_vopops.c:487-492) charges / enforces against the wrong, unrelated mount. 3. In the race window (exists() passes -> unmount completes -> kfree -> use), VFS_ACCOUNT/vfs_stdaccount (sys/kern/vfs_quota.c:149-172) operates on freed struct mount memory (stale mnt_op read, spin_lock(&mp->mnt_acct.ac_spin) write, ac_bytes += delta with an attacker-influenced delta). On this kernel's slab allocator the freed chunk retains its contents, so the practical outcome is silent corruption of freed-memory state / wrong-mount accounting rather than a wild write.

Deterministic user-visible manifestation (needs vfs.quota_enabled=1, a boot tunable — default 0):

• extend a file through the lower mount whose vnode has a stale v_pfsmp -> the write is quota-checked against the new, unrelated nullfs mount -> EDQUOT from a tmpfs that has no limits, or
• : > lowerfile (O_TRUNC) -> vfs_stdaccount(freed/wrong mp, uid, gid, -osize) -> the unrelated mount's reported usage goes negative.

Build

No compilation needed — pure shell against stock userland (/sbin/mount_null, /sbin/vquota, dd, su).

Run

As root on the guest (the actor is unprivileged user qa):

./run.sh

Expected output (success criteria)

1. CONTROL append through the lower mount with NO nullfs alive: succeeds.
2. vquota set limit /mnt/alias2 10, then the same append through the lower mount: fails with Disk quota exceeded (EDQUOT) — enforcement against the wrong mount (the stale v_pfsmp address now equals alias2's struct mount).
3. vquota get usage /mnt/alias2 reports negative bytes after an O_TRUNC through the lower mount (the -osize account delta landed on alias2).

Environment

• DragonFly 6.5-DEVELOPMENT #0 (stock INVARIANTS kernel)
• vfs.quota_enabled=1 added to /boot/loader.conf (tunable; sysctl is RD)
• tmpfs lower mount, two sequential nullfs mounts (address reuse via M_MOUNT zone LIFO)

DF-2774 — VERDICT

Status: reproduced (deterministic, no race needed for the primary manifestation). Impact: cross-mount VFS accounting corruption + wrong-mount quota enforcement (EDQUOT) driven by a stale vp->v_pfsmp pointer that mountlist_exists() fails to validate; a narrower concurrent-unmount variant is a use-after-free of struct mount. No uid0 path; the memory-unsafety ceiling is bounded by M_MOUNT-zone type-stability (see below). Requires non-default boot tunable vfs.quota_enabled=1 for any user-visible effect (default 0 makes VFS_ACCOUNT a no-op) plus nullfs stacking — hence Medium, not High.

Root cause (path:line)

1. sys/kern/vfs_cache.c:1386-1389 — _cache_setvp(): when a vnode is resolved through a namecache entry owned by a nullfs mount, the lower filesystem's vnode is tagged vp->v_pfsmp = mp (the nullfs struct mount). The pointer is raw: no reference, never cleared on unmount (only bzero of the whole vnode on reclaim clears it, vfs_lock.c:1200).
2. sys/kern/vfs_syscalls.c:1040,1117 — dounmount() removes the nullfs mount from the mountlist, waits for mnt_refs, then mount_drop() → kfree(mp, M_MOUNT) (sys/kern/vfs_mount.c:399-405). v_pfsmp is not an mnt_refs/mnt_hold reference, so nothing stops the free.
3. sys/kern/vfs_mount.c:692-708 — mountlist_exists() walks the mountlist comparing pointers only, under the shared mountlist token, and returns without taking any reference. The in-tree FIXME at sys/kern/vfs_mount.c:689-691 admits the guarantee is absent.
4. sys/kern/vfs_quota.c:421-433 — vq_vptomp() uses that check as a lifetime guard and hands the stale pointer to: - sys/kern/vfs_vnops.c:325-326 — vn_open() O_TRUNC path: VFS_ACCOUNT(mp, uid, gid, -osize); - sys/kern/vfs_vopops.c:487-496 — vop_write(): vq_write_ok(mp,…) (mount-wide/uid/gid limit enforcement) and post-write VFS_ACCOUNT.
5. sys/kern/vfs_quota.c:149-172 — vfs_stdaccount() then does spin_lock(&mp->mnt_acct.ac_spin), ac_bytes += delta (attacker- influenced 64-bit delta via write sizes / O_TRUNC sizes) and RB-tree walks on the (possibly freed) struct mount.

Two manifestations

(a) Deterministic type confusion (reproduced, see run.log): after the nullfs mount is unmounted, mountlist_exists(stale) compares the stale address against the current mountlist. A fresh mount_null re-uses the just-freed M_MOUNT chunk (zone LIFO), so the stale pointer compares equal to the new, unrelated mount and the guard passes. Observed on stock kernel #0 with vfs.quota_enabled=1:

• TEST1: append through the lower tmpfs (which has no limits) failed with dd: stdout: Disc quota exceeded (EDQUOT, 0 bytes written) — the unrelated alias2 nullfs mount's 10-byte limit was enforced because the stale v_pfsmp now aliases alias2's struct mount.
• TEST2: : > /mnt/lower/victim (O_TRUNC through the lower path) charged −8192 to alias2: vquota show /mnt/alias2 → total: 18446744073709543424, limit = 10 (2^64−8192).
• Controls behaved correctly (append succeeds when no mount occupies the stale address; charges then land on vp->v_mount).

An unprivileged user observes/triggers both effects (the write/truncate is theirs); mounting/unmounting is privileged, but nullfs stacking with later unmount is normal admin/jail/automounter behavior — the poisoned vnodes persist after the admin action, and the confusion is armed deterministically by the next mount that recycles the chunk.

(b) Use-after-free race (analyzed, not raced on the guest): between mountlist_exists() returning 1 and VFS_ACCOUNT/vq_write_ok dereferencing mp, dounmount() can complete and kfree() the mount. Reads: mp->mnt_op (mount.h:657-659), and with quota enabled, vfs_stdaccount() writes the freed chunk (spin_lock, ac_bytes +=). Practical ceiling on this kernel: DFly's slab allocator keeps freed chunk contents intact (no freelist pointers embedded in the payload), quota RB nodes are never freed (vfs_quota.c:142-146 "TODO"), and the M_MOUNT zone serves only struct mount allocations — so the realistic outcome of a hit is silent corruption of freed-mount state or the (a)-style confusion once the chunk is re-allocated, not a wild write / RIP control. I therefore did not chase uid0 from this primitive; the honest classification is logic-corruption + UAF-read/limited-UAF-write.

Why the default config is unaffected

vfs_quota_enabled defaults to 0 (sys/kern/vfs_quota.c:112-115, TUNABLE_INT). With it 0, VFS_ACCOUNT reduces to a NULL check of the stale-but-intact mnt_op->vfs_account (still pointing at the live static null_vfsops), i.e. a benign read of freed-but-intact memory.

Fix validation (fix.diff, kernel #1 built in-guest)

make -j6 nativekernel KERNCONF=X86_64_GENERIC (361s) + installkernel + reboot; exact same poc.sh re-run (run.fix.log):

• TEST1 append now succeeds (TEST1_RC=0, 4096 bytes transferred) — no EDQUOT from the unrelated mount.
• vquota show /mnt/alias2 stays total: 0, limit = 10 — no stale charge.
• The intended alias accounting still works (creation through alias charges the nullfs mount 4096; lower stays 0) — feature preserved.

fix.diff adds mountlist_hold() (a real-hold variant of mountlist_exists(), sys/kern/vfs_mount.c), a unique mnt_cookie generation per struct mount, v_pfsmp_cookie on struct vnode, and a held+cookie-validated vq_vptomp() whose callers mount_drop() after accounting (vfs_quota.c, vfs_vnops.c, vfs_vopops.c, vfs_cache.c).

Attempts / notes

4 guest runs: run2 (tooling: DFly dd/vquota syntax), run3 (ordering: victim must be resolved through the alias first — an already-resolved ncp never re-runs _cache_setvp), run4 = decisive baseline, fixrun = patched. Guest dirtied (loader.conf tunable, user qa, patched kernel, patched /usr/src) — reset via vm.sh reset with-src after evidence collection. Baseline kernel: DragonFly 6.5-DEVELOPMENT #0 Thu Jul 2 06:02:54 UTC 2026; patched: #1 Sep 1 02:11:26 UTC 2026.