# 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.