# DF-3191 — VERDICT

**status: reproduced / impact: panic (kernel memory corruption machinery, root-gated)**

## Baseline run (stock INVARIANTS kernel #0, fuse.ko stock)

```
$ cc -O2 -Wall -o dm dm.c && kldload fuse && ./dm
[995] opened /dev/fuse fd=3
[995] daemon loop on fd 3
[995] REQ op=26 unique=0          <- mount A FUSE_INIT
[995] REQ op=17 unique=1          <- mount A mount-time FUSE_STATFS
[996] mount(/mnt/dfa) OK
[995] REQ op=26 unique=2          <- mount B FUSE_INIT on the SAME fd (no guard)
[995] REQ op=17 unique=3          <- mount B mount-time FUSE_STATFS
```
serial console (run.log / panic.txt):
```
fuse_mount(dm|996): FUSE UABI 7.28
fuse_mount(dm|996): FUSE UABI 7.28
panic: assertion "fmp->rfnp->vp == NULL" failed in fuse_unmount at /usr/src/sys/vfs/fuse/fuse_vfsops.c:281
fuse_unmount() at fuse_unmount+0x419
sys_unmount() at sys_unmount+0x1f2 ...
```

Exactly the analyzed chain: both mounts succeed on one `fmp`
(sys/vfs/fuse/fuse_vfsops.c:168-199 — no re-association guard); mount A's
`umount` then inspects/frees **mount B's** root node (`fmp->rfnp` was
overwritten at fuse_vfsops.c:194): the KKASSERT at fuse_vfsops.c:281
trips because B's post-mount path already instantiated B's root vnode.
Guest wedged in ddb (`vm.sh status` ⇒ down); fresh state each run —
repeated twice (identical panic both times, see run.log and the fix-phase
baseline below).

## Why it is memory corruption, not just a panic

With file activity on mount A before the second mount, A's nodes sit in
the tree that mount B's `RB_INIT()` (fuse_vfsops.c:183) detaches. Mount
A's unmount then reclaims A's vnodes; `fuse_vop_reclaim` exempts only
`fmp->rfnp` — which is B's root now — so A's nodes go through
`fuse_node_free()` → `RB_REMOVE()` on a tree they are no longer in.
DFly's `RB_REMOVE` (sys/sys/tree.h:585-656) does **not** search the tree;
it splices on the node's own stale links, and when the stale
`RB_PARENT(elm) == NULL` it executes `RB_ROOT(head) = child`
(tree.h:651-652), **replacing mount B's live tree root with a stale
subtree pointer**. Nodes in that subtree are subsequently freed via
objcache and recycled → every later lookup/walk on mount B is a UAF.
The deterministic panic observed here is the simplest manifestation; the
splice corruption is reachable by adding lookups on /mnt/dfa between the
mounts.

## Exploit chain (why it stops at root)

The trigger requires two mount(2) calls, i.e. mount privilege.
`fuse_mount()` requires `caps_priv_check(cred, SYSCAP_NOMOUNT_FUSE)`
(fuse_vfsops.c:153-155); `SYSCAP_NOMOUNT_FUSE = __SYSCAP_GROUP_10 | 4 =
0xA4` (sys/caps.h:227) has neither `__SYSCAP_NOROOTTEST` (0x40000) nor
`__SYSCAP_WHEELOK` (0x80000), so `caps_priv_check` returns EPERM for any
cred with uid != 0 (sys/kern/kern_caps.c:328-331) — even with
`vfs.usermount=1` a non-root user cannot reach this code. No
unprivileged→root chain; severity is "root-gated kernel memory
corruption + DoS".

## Fix validation

- `fix.diff` (authored after reproduction, applied to the guest's
  /usr/src, fuse.ko rebuilt in /usr/src/sys/vfs/fuse, installed, reboot):
  baseline re-verified (panic reproduced again on the unpatched boot),
  then patched run:
```
[855] mount(/mnt/dfa) OK
[855] mount(/mnt/dfb) FAILED: Device busy      <- EBUSY from the guard
[855] second mount refused (FIXED?)
```
  No panic; guest stays up (fix_run.log, fix_build_tail.log).

## Kernel references

- sys/vfs/fuse/fuse_vfsops.c:152-199 (no re-association guard; re-init of live locks/lists/tree; rfnp overwrite at :194)
- sys/vfs/fuse/fuse_vfsops.c:266-294 (unmount frees the *other* mount's rfnp; KKASSERT :281)
- sys/vfs/fuse/fuse_vnops.c:1786-1801 (fuse_vop_reclaim exempts only fmp->rfnp)
- sys/sys/tree.h:585-656 (RB_REMOVE splice without membership check; root overwrite at :651-652)
- sys/kern/vfs_syscalls.c:344-349 (`hasmount` guards the mountpoint, not the device)
- sys/kern/kern_caps.c:328-331 + sys/caps.h:227 (mount is uid-0-only)

## Fix status (batch validation)
Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest `make -j6 nativekernel KERNCONF=X86_64_GENERIC` completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.