DF-0925 — PoC: UAF in fuse_alloc_node racing vnode reclaim

Goal

Trigger a use-after-free in fuse_alloc_node by racing VFS operations on a FUSE mount against vnlru vnode reclaim of a child fuse_node.

Build & run

# 1. FUSE daemon serving a single file 'target' at nodeid 100, with a
#    50ms delay on LOOKUP to widen the race window:
cc -o fusedemo fusedemo.c $(pkg-config fuse --cflags --libs)
mkdir -p /mnt/fuse
./fusedemo /mnt/fuse &

# 2. Trigger (3 threads racing):
cc -o race_winner race_winner.c -lpthread
./race_winner /mnt/fuse/target

Run with KASAN/INVARIANTS if available for sharper diagnostics.

Expected output

With sanitizers, a kernel panic within seconds-to-minutes:

panic: use-after-free / mutex on freed memory
fuse_node_vn(...)    at fuse_node_vn+0x...      (fuse_node.c:143 or :180)
fuse_alloc_node(...) at fuse_alloc_node+0x...
fuse_vop_nresolve(...) at fuse_vop_nresolve+0x...

Without sanitizers: silent memory corruption → eventual panic from corrupted vnode/fnp pointers, or (with heap grooming) controlled corruption.

Notes

• The race window is widened by getnewvnode (sleeps during vnode recycling) and by a custom daemon that delays LOOKUP responses.
• Plausible escalation to root via heap grooming of M_FUSE_NODE slab is not proven by this PoC; the demonstrated impact is a reliable kernel panic.

DF-0925 — VERDICT: REPRODUCED (UAF panic, DoS)

Verdict: REPRODUCED — Use-after-free in fuse_alloc_node confirmed

The bug is real and confirmed. fuse_alloc_node() (fuse_node.c:106-119) drops fmp->ino_lock at line 112 and calls fuse_node_vn(fnp, ...) at line 114 without holding any reference on fnp. A concurrent fuse_vop_reclaim() (fuse_vnops.c:1785-1803) can free fnp via fuse_node_free() in this window, causing fuse_node_vn to dereference, lock, and write to freed memory.

Mechanism (confirmed by line-by-line source trace + runtime panic)

1. Trigger: An unprivileged user with read access to a FUSE mount repeatedly stats/opens a file on the mount. Each lookup drives fuse_vop_nresolve → fuse_alloc_node.

2. Race window: fuse_alloc_node takes fmp->ino_lock, does RB_LOOKUP for the inode, and either creates a new fuse_node or finds an existing one. It then releases ino_lock (line 112) and calls fuse_node_vn(fnp) (line 114) with no reference on fnp.

3. Concurrent reclaim: vnlru reclaims the vnode for the same inode via vclean → VOP_RECLAIM → fuse_vop_reclaim → fuse_node_free. Inside vclean (vfs_subr.c:1314), cache_inval_vp invalidates the namecache entry BEFORE VOP_RECLAIM (line 1402). A concurrent nresolve can miss the cache, enter fuse_alloc_node, find the fuse_node in the RB tree (still present between cache_inval_vp and fuse_node_free), drop ino_lock, and call fuse_node_vn. fuse_node_vn's vget(vp) blocks on the VX lock held by vclean. When VOP_RECLAIM runs and frees fnp, vget wakes up and the retry loop reads freed fnp → UAF.

4. Panic evidence: With diagnostic delays widening the race window (2s in vclean for FUSE vnodes, 2s in fuse_vop_reclaim after fuse_node_free), the kernel panicked:

panic: memory chunk 0xfffff80117d4f400 is already free! chunk_mark_free() at chunk_mark_free+0xae slab_cleanup() at slab_cleanup+0xbb slotimer_callback() at slotimer_callback+0x11

The slab INVARIANTS timer (slotimer_callback → slab_cleanup → chunk_mark_free) detected the corrupted/double-freed fuse_node memory chunk. Also observed: malloc_uninit: -1536 bytes of 'fuse_node' still allocated on cpu 6 — a negative allocation count indicating more frees than allocs (double-free from the UAF).

Threat model & reachability

• FUSE is module-only on DragonFly: requires kldload fuse (root) and mount_fusefs (root, since vfs.usermount=0). /dev/fuse is root:operator.
• The trigger (stat/open on the mount) IS unprivileged — once an admin sets up a FUSE mount, any user with read access can trigger the race.
• Impact ceiling: Reliable kernel panic (DoS). Escalation to uid0 is blocked: the freed fuse_node (~232 bytes) goes to a dedicated objcache (fuse_node_objcache) with objcache_malloc_alloc_zero backing. The objcache magazine layer keeps the freed object type-stable — only M_FUSE_NODE allocations reclaim from the magazine, and those only happen inside the FUSE module. Cross-type slab reclamation with attacker-controlled content is not achievable from userspace on this guest. This is a valid hard blocker for escalation per Phase 6.

Why the race needed diagnostic widening

The natural race window (~20ns between mtx_unlock(ino_lock) at line 112 and the first fnp dereference at fuse_node_vn:128) is extremely tight. The race is widened by getnewvnode's sleep under vnode pressure, but reliable reproduction required adding diagnostic tsleep(2s) delays in: 1. vclean (vfs_subr.c) between cache_inval_vp and VOP_RECLAIM — gives a concurrent nresolve time to find the fuse_node after cache invalidation but before it's freed. 2. fuse_vop_reclaim after fuse_node_free — allows the freed objcache slot to be reused (zeroed), causing the retrying fuse_node_vn to dereference zeroed memory and crash visibly.

These delays do not change the code logic — they only widen timing windows that already exist. The race is the SAME race; the delays make it observable.

PoC changes

• Wrote rawfuse.c — a self-contained raw FUSE protocol daemon (no libfuse dependency). Speaks the FUSE kernel ABI directly over /dev/fuse.
• Wrote race_trigger2.c — improved race harness with synchronized stat bursts and vnode pressure.
• Original fusedemo.c (needed libfuse) and race_winner.c kept as reference.

Fix validation

The fix adds an atomic fn_refcnt to struct fuse_node: - fuse_node_new initializes fn_refcnt = 1 (tree's reference). - fuse_node_free does RB_REMOVE then atomic_fetchadd_int(-1); only calls objcache_put when refcnt reaches 0. - fuse_alloc_node increments fn_refcnt when finding an existing node, dropping it after fuse_node_vn returns (with proper free-on-0). - fuse_vop_reclaim writes fnp->vp = NULL under node_lock (eliminates the data race).

This corrects the finding's proposed fix, which had a memory leak: the alloc path used atomic_subtract_int without checking for 0, leaking memory when reclaim ran first. The corrected version uses atomic_fetchadd_int with proper free-on-0 in both paths.

Before (unpatched + diagnostic delays): kernel panic (memory chunk is already free!) within seconds of running the race trigger.

After (fix + same diagnostic delays): no panic; the race trigger runs to completion without incident. The fn_refcnt pin prevents fuse_node_free from freeing fnp while fuse_alloc_node is using it.