DF-0926 — PoC: type-confusion panic via daemon nodeid reuse

Goal

Trigger a deterministic kernel panic by serving a FUSE mount that returns the same nodeid for two different operations with conflicting types (e.g., S_IFREG for one file, S_IFDIR for a directory created later). The kernel hits KKASSERT(vap->va_type == fnp->type) at fuse_vnops.c:81, which fires unconditionally because INVARIANTS is forced on at fuse.h:31-33.

Build & run

cc -o fusedemo fusedemo.c $(pkg-config fuse --cflags --libs) -D_FILE_OFFSET_BITS=64
mkdir -p /mnt/fuse
./fusedemo /mnt/fuse &

# In another shell (any user with access to /mnt/fuse):
ls /mnt/fuse/baitfile    # creates fuse_node(100, VREG)
mkdir /mnt/fuse/crashdir # daemon returns nodeid=100 as VDIR -> KKASSERT panic

Expected output

panic: vap->va_type == fnp->type
cpuid = ...
Trace begins at ...
fuse_set_attr(...)    at fuse_set_attr+0x...      (fuse_vnops.c:81)
fuse_vop_nmkdir(...)  at fuse_vop_nmkdir+0x...
vop_nmkdir(...)       at vop_nmkdir+0x...

The system halts. 100% reproducible, no race required.

Notes

• Any user with read+execute on the FUSE mount can trigger this; the malicious behavior is entirely on the daemon side.
• If INVARIANTS were ever removed from fuse.h, the KKASSERT becomes a no-op and the type confusion proceeds silently — at which point it becomes a confused-deputy vector rather than a panic.

DF-0926 — VERDICT

Verdict: REPRODUCED. Type-confusion panic in fuse_alloc_node when a malicious FUSE daemon reuses a previously-allocated nodeid for a node of a different type (file→dir or dir→file). Trigger is unprivileged (any user with access to the mount). Impact is kernel panic / DoS (no memory corruption primitive; the KKASSERT halts the kernel before any further state damage).

Mechanism (every hop cited)

1. Daemon creates a VREG node at ino=100. A user performs ls /mnt/fuse/baitfile; the kernel sends FUSE_LOOKUP("baitfile") and the daemon replies with fuse_entry_out{nodeid=100, attr.mode=S_IFREG}. The kernel's fuse_vop_nresolve (sys/vfs/fuse/fuse_vnops.c:571) calls fuse_alloc_node(fmp, dfnp, 100, VREG, &vp).

2. fuse_alloc_node (sys/vfs/fuse/fuse_node.c:106-114) is buggy. It does RB_LOOKUP for the nodeid, and when found it proceeds with the existing node — vtyp is silently ignored: c fnp = RB_LOOKUP(fuse_node_tree, &fmp->node_head, ino); if (fnp == NULL) { fuse_node_new(fmp, ino, vtyp, &fnp); /* vtyp used only for new nodes */ allocated = 1; } mtx_unlock(&fmp->ino_lock); error = fuse_node_vn(fnp, vpp); /* uses existing fnp->type */

3. Daemon returns the same nodeid for an MKDIR. User runs mkdir /mnt/fuse/crashdir; the kernel sends FUSE_MKDIR("crashdir") and the daemon replies with fuse_entry_out{nodeid=100, attr.mode=S_IFDIR}. fuse_vop_nmkdir (sys/vfs/fuse/fuse_vnops.c:915) verifies IFTOVT(feo->attr.mode) == VDIR (passes), then calls fuse_alloc_node(fmp, dfnp, 100, VDIR, &vp) at :920. This returns the existing VREG vnode with vp->v_type = fnp->type = VREG.

4. fuse_set_attr panics. fuse_vop_nmkdir then calls fuse_set_attr(fnp, &feo->attr) (sys/vfs/fuse/fuse_vnops.c:927). Inside fuse_set_attr: c vap->va_type = IFTOVT(fat->mode); /* fuse_vnops.c:56 -> VDIR */ ... KKASSERT(vap->va_type == fnp->type); /* fuse_vnops.c:81 -> VDIR != VREG */ The KKASSERT always fires in production because INVARIANTS is unconditionally forced on at sys/vfs/fuse/fuse.h:31-33.

5. Kernel halts. Captured panic signature (from dfbsd-qemu/boot.log): panic: assertion "vap->va_type == fnp->type" failed in fuse_set_attr at /usr/src/sys/vfs/fuse/fuse_vnops.c:81 fuse_set_attr() at fuse_set_attr+0x199 fuse_vop_nmkdir() at fuse_vop_nmkdir+0x1b3 vop_nmkdir() at vop_nmkdir+0x5b kern_mkdir() at kern_mkdir+0xf2 sys_mkdir() at sys_mkdir+0x51 Stopped at Debugger+0x7c: movb $0,0xbdaf09(%rip)

Why this is a valid DoS finding

• Trigger is unprivileged. Only the daemon side requires root/operator privilege (to open /dev/fuse and call mount); the triggering syscall (mkdir) is performed by the unprivileged maxx user (uid=1001).
• Realistic precondition. A FUSE filesystem daemon is, by the DragonFly FUSE design contract, a partially-trusted userspace peer (see comments in fuse_vnops.c and the FUSE protocol). Any malicious or compromised daemon can mount this attack and crash the kernel whenever any user creates a directory on the mount. No race, no timing — 100% reliable.
• Reachability is the default. The bug is compiled in unconditionally via fuse.h:31-33's forced INVARIANTS. No custom kernel build is required. mount_fusefs and fuse.ko ship with the master DEV build.

Why this is DoS-only (no escalation attempted)

The primitive is a panic halt, not a memory write. The KKASSERT expands to panic() before fuse_set_attr returns, so no caller ever sees the type-confused vnode pointer as a usable primitive. There is no heap/stack corruption, no UAF, no function-pointer overwrite. The bug class is type confusion but the effect in production is purely DoS because INVARIANTS traps it at the assertion boundary. The runner instructions' Phase-6 escalation bar (write/UAF/double-free/type-confusion with a write primitive) does not apply — the write-able corruption exists only on a hypothetical INVARIANTS-OFF kernel, which is a non-default build; on default GENERIC the bug is DoS-only. The finding markdown itself classifies this correctly as Medium severity CVSS AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H (DoS only).

PoC changes from initial scaffolding

• The provided fusedemo.c used libfuse (the <fuse.h> userland library and fuse_main()), which is not installed on the DragonFly master DEV guest (no pkgsrc, no /usr/local/lib/libfuse*, no pkg-config). Rewrote as a standalone daemon (fusedev.c) that speaks the FUSE kernel ABI directly over /dev/fuse — open the device, fork/exec mount_fusefs fd mountpoint, then read/write the FUSE protocol structures from fuse_abi.h inline.
• Initial trigger attempt returned EEXIST because the daemon's FUSE_LOOKUP handler also answered crashdir (pre-populating the namecache as a positive entry). Fixed: FUSE_LOOKUP("crashdir") now returns ENOENT; only FUSE_MKDIR("crashdir") returns the conflicting nodeid=100/VDIR entry.
• Second attempt returned EACCES because the daemon reported the root dir as mode=0755, blocking the unprivileged trigger user's write via the kernel-side naccess_lva (sys/kern/vfs_nlookup.c:1780) pre-check. Fixed: root inode reports mode=S_IFDIR|0777 so the unprivileged user can attempt the mkdir.

Reproduction

• Build: cc -o fusedev fusedev.c (succeeds on DragonFly gcc 8.3).
• Setup (as root): kldload fuse; ./fusedev /mnt/fuse & (mounts the malicious daemon).
• Trigger (as any user): ls /mnt/fuse/baitfile && mkdir /mnt/fuse/crashdir.
• Expected: kernel panic at fuse_set_attr+0x199, full halt at DDB prompt. Serial console (dfbsd-qemu/boot.log) captures the trace.

Exploit chain

Not applicable (DoS-only primitive — see above). The bug is a KKASSERT panic; there is no write primitive on the default INVARIANTS-on GENERIC kernel to convert into uid=0.

Files in this evidence pack

• fusedemo.c — original libfuse-based daemon (kept for reference; does not build on this guest because libfuse is absent).
• fusedev.c — working standalone FUSE daemon (no libfuse), the one that actually triggers the panic.
• trigger.sh — the unprivileged ls && mkdir sequence.
• build.sh / run.sh — exact reproducible build/run commands.
• panic.txt — the captured panic stack trace from dfbsd-qemu/boot.log.
• env.txt — guest uname/kern.version/cc/sysctl at verification time.
• fix.diff — minimal git-apply-able fix (see below).
• fix_build.log — full build output of the patched fuse.ko module.
• fix_run.log — decisive post-fix PoC run (3× — deterministic, no panic).
• fix_env.txt — patched-kernel environment (kern.version, fuse.ko sha256, patched source excerpt).
• manifest.json — machine-readable catalog.

Fix validation (Phase 8)

The bug lives in the FUSE module (fuse.ko), not the kernel image proper. So instead of rebuilding the entire kernel, I rebuilt only fuse.ko from the patched source and swapped it in via kldload. This validates the same source code change as a full kernel rebuild would — the loader just gets the patched module through a different mechanism.

Setup: 1. Reset to with-src baseline (unpatched 6.5-DEVELOPMENT #0, source 6cc80ee9, warm obj). 2. Confirmed baseline reproduction: the panic at fuse_set_attr+0x199 fires (see panic.txt) — fix_baseline_reproduced=1. 3. Applied fix.diff to /usr/src/sys/vfs/fuse/fuse_node.c (patch -p1 --forward, "Hunk #1 succeeded at 108"). 4. Built only the patched module: cd /usr/src/sys/vfs/fuse && make (fix_build.log, BUILD_RC=0, produced /usr/obj/usr/src/sys/vfs/fuse/fuse.ko sha256 5a4e2a701cdeb13065cd1daafa8482a09b541f7fb278341175ea905bfdc18ee1). 5. Installed it: cp fuse.ko /boot/kernel/fuse.ko; kldload fuse. 6. Re-ran the same trigger (same daemon, same trigger.sh).

Before (unpatched baseline):

[trigger] mkdir /mnt/fuse/crashdir (daemon reuses ino=100 as VDIR -> KKASSERT panic)
<ssh session dies; guest down>
panic: assertion "vap->va_type == fnp->type" failed in fuse_set_attr
    at /usr/src/sys/vfs/fuse/fuse_vnops.c:81
fuse_set_attr() at fuse_set_attr+0x199
fuse_vop_nmkdir() at fuse_vop_nmkdir+0x1b3

After (patched fuse.ko, 3 deterministic runs):

[trigger] mkdir /mnt/fuse/crashdir (daemon reuses ino=100 as VDIR -> KKASSERT panic)
mkdir: /mnt/fuse/crashdir: Invalid argument
[trigger] mkdir rc=1
[trigger] if you read this, the kernel did not panic

The patched kernel returns EINVAL (the value the fix returns from fuse_alloc_node when the daemon's claimed type conflicts with the existing node's type) — exactly the contract the finding markdown's recommended fix describes ("The caller already handles EINVAL from fuse_alloc_node"). The guest stays up; the panic is gone. fix_patched_reproduced=0, fix_status=fixed.

Verdict: the fix closes the bug. It matches the finding markdown's recommended fix exactly.