DF-0780 — Heap buffer overflow in fuse_io_execute READ (oversized daemon reply)

Reproduction + fix-validation evidence pack.

What this proves

fuse_io_execute() (sys/vfs/fuse/fuse_vnops.c:2054) copies a FUSE daemon's READ reply into a kernel buffer-cache buffer with memcpy(bp->b_data, fuse_out_data(fip), fuse_out_data_size(fip)) and no check that fuse_out_data_size <= bp->b_bcount. The only existing guard, fuse_audit_length() in fuse_device_write(), is advisory: on failure it returns EPROTO to the daemon's write() only, while still completing the IPC with ohd->error == 0; so fuse_ipc_tx() returns success and the unchecked memcpy runs with the daemon-chosen length. A daemon that replies with more bytes than requested overflows bp->b_data.

Files

• evil_daemon.c — self-contained raw /dev/fuse malicious daemon. Mounts a synthetic FUSE fs (/mnt/fuse) exposing target (8192 bytes) and answers every FUSE_READ with 131072 bytes.
• build.sh — cc -O0 -g -o evil_daemon evil_daemon.c
• run.sh — loads fuse, starts the daemon (root), then reads the file as maxx to trigger the overflow.
• fix.diff — consumer-side bound check in fuse_io_execute (validated).
• build.log / run.log / fix_run.log / fix_build.log / panic.txt / env.txt / VERDICT.md / manifest.json.

Reproduce (panic / proof of overflow)

On the audit guest (unprivileged maxx exists; root needed only to load the module and open /dev/fuse):

# as root, on the guest:
cp /usr/obj/usr/src/sys/X86_64_GENERIC/usr/src/sys/vfs/fuse/fuse.ko /root/fuse.ko
# as maxx:
cd poc/DF-0780 && sh build.sh
# as root:
sh run.sh            # maxx reads /mnt/fuse/target -> kernel panics

Expected on the unpatched kernel: guest dies, dfbsd-qemu/boot.log shows

panic: assertion "obj != NULL" failed in vm_object_hold_shared ...
--- trap 000000000000000c ---
memcpy() at memcpy+0xfa

Validate the fix

scp fix.diff dfbsd:/root/fix.diff
vm.sh run_root 'cd /usr/src && patch -p1 --forward < /root/fix.diff'
vm.sh run_root 'cd /usr/src/sys/vfs/fuse && make obj && make && \
                cp fuse.ko /root/fuse.ko'
vm.sh run_root 'cd /usr/src && nohup sh -c "make -j6 nativekernel \
                KERNCONF=X86_64_GENERIC; echo done" </dev/null >/root/nk.log 2>&1 &'
# …poll /root/nk.log for "done"…
vm.sh run_root 'cp /usr/obj/.../kernel.stripped /boot/kernel/kernel; \
                cp /usr/obj/.../kernel.debug /boot/kernel/kernel.debug'
vm.sh down && vm.sh up
sh run.sh           # maxx reads -> cat: Invalid argument, NO panic, guest up

Threat model / scope (read VERDICT.md for detail)

The trigger is root-only on default DragonFly (kldload + /dev/fuse root:operator 0660 + mount capability check all require root), so this is a root→kernel hardening gap / DoS, not an unprivileged→root escalation on a default system. The bug is a genuine memory-safety defect and is fixed.

DF-0780 — Verdict

Heap buffer overflow in fuse_io_execute READ from oversized daemon reply

Verdict: REPRODUCED (heap OOB write → panic); fix VALIDATED

1. The bug — confirmed at source and at runtime

fuse_io_execute() handles buffered READ on a FUSE filesystem (sys/vfs/fuse/fuse_vnops.c:2031). For BUF_CMD_READ it allocates an IPC, sets the requested size to the buffer length, transacts it, and on success copies the daemon's reply into the kernel buffer with no bound check:

/* fuse_vnops.c:2044 */
case BUF_CMD_READ:
    fip = fuse_ipc_get(fmp, sizeof(*fri));
    fri = fuse_ipc_fill(fip, FUSE_READ, fnp->ino, proc0.p_ucred);
    fri->offset = bp->b_loffset;
    fri->size   = bp->b_bcount;          /* requested size == buffer size */
    fri->fh     = fnp->fh;
    error = fuse_ipc_tx(fip);
    if (error == 0) {
        memcpy(bp->b_data, fuse_out_data(fip),
               fuse_out_data_size(fip));   /* <-- NO check vs bp->b_bcount */
        ...

bp->b_data is a buffer-cache buffer of bp->b_bcount bytes (FUSE_BLKSIZE = 4096 for a single block, or a cluster of up to MAXBSIZE via cluster_readx, fuse_vnops.c:1373). fuse_out_data_size(fip) is the daemon-chosen reply length (fip->reply.len - sizeof(fuse_out_header), fuse.h:270).

The finding's whole point is that the only existing size guard is advisory only. fuse_device_write() (fuse_device.c:165) receives the daemon's reply, fuse_buf_alloc()s a buffer of the full daemon write size (line 182), stores it as fip->reply (line 205), then runs fuse_audit_length() (line 212). When the audit fails it sets a local error = EPROTO that is returned only to the daemon's write() syscall (line 213, 222); it does not set ohd->error, and the IPC is completed and the waiter woken regardless (lines 219-220). Consequently fuse_ipc_tx() (fuse_ipc.c:247) only sees ohd->error == 0 and returns 0 (success), so fuse_io_execute enters the error == 0 branch and performs the unchecked memcpy with the daemon-controlled length.

So a daemon that replies to FUSE_READ with N > requested bytes makes the kernel memcpy N bytes into a smaller buffer ⇒ heap OOB write of N - bp->b_bcount bytes past bp->b_data.

2. Live reproduction

evil_daemon.c is a self-contained raw /dev/fuse protocol daemon that: opens /dev/fuse, mounts a synthetic FUSE filesystem exposing one regular file target (inode 2, size 8192), serves FUSE_INIT/STATFS/GETATTR/LOOKUP/ OPEN/READ, and answers every FUSE_READ with 131072 bytes (REPLY_DATA_SIZE) regardless of the requested size.

It is built and started as root (it must open /dev/fuse and mount). The overflow itself is triggered by the unprivileged user maxx reading the file: cat /mnt/fuse/target.

Result on the unpatched audit-source kernel (#0) + stock fuse.ko, deterministic 3/3 fresh-reset runs:

[daemon] READ node=2 off=0 reqsize=8192  REPLYING 131072 bytes (OVERFLOW 122880 past reqsize buf)
panic: assertion "obj != NULL" failed in vm_object_hold_shared at vm_object.c:330
--- trap 000000000000000c, rip = ffffffff80bcac8a ---
memcpy() at memcpy+0xfa
db>

trap 0xc is a page fault; the faulting RIP is inside memcpy() — i.e. the OOB write in fuse_io_execute ran off the end of bp->b_data's mapped KVA into an unmapped page. vm_fault then dereferenced a corrupted/out-of-range vm_object and panicked on obj != NULL. The fault originates in exactly the unchecked memcpy the finding names, on the FUSE READ path.

3. Primitive characterization

• what the attacker controls: the overflow content (the reply bytes — fully attacker-chosen) and the overflow size (fuse_out_data_size = whatever the daemon writes minus 16). This is a strong arbitrary-content heap-write primitive in principle.
• where it lands: bp->b_data is a buffer-cache KVA buffer, not a slab object. The overflow runs into adjacent buffer-cache KVA (another buffer's data, or — as observed — an unmapped page). This is not the slab heap, so the classic slab-grooming → function-pointer/ucred overwrite technique does not transfer directly.
• observed behaviour on the default GENERIC (INVARIANTS-on) guest: the write page-faults immediately (no graceful corruption window on this run).

4. Exploit chain to uid=0 — BLOCKED by a valid hard blocker

Per Phase 6, the chain to uid=0 must be exercisable by an unprivileged user end-to-end. This bug is not, and I verified there is no unprivileged path:

All three preconditions are root-only on a default DragonFly system. mount_fusefs is not setuid, vfs.usermount=0, and no FUSE mount exists by default. An unprivileged user therefore cannot be the daemon (cannot open /dev/fuse) and cannot shape the overflow, so there is no unpriv→root escalation. This is the valid hard blocker enumerated in Phase 6: "the write is reachable only from an already-root context (… devfs root:operator node with no group membership …), so there is no privilege boundary to cross (root→kernel is game-over by definition)."

I did not fabricate a uid=0. I exhausted the unprivileged paths (/dev/fuse perms, setuid helpers, devfs rules, default mounts) — none exist. The realistic impact is therefore:

• root → kernel: a malicious or compromised root-run FUSE daemon can corrupt kernel memory. This is a hardening gap / DoS — root can already kldload an arbitrary module, so it is not a new privilege boundary.
• operator → root: an operator-group member can open /dev/fuse and run the daemon, but still cannot mount FUSE without root (capability check), so even operator cannot self-trigger the bug on a default system.
• DoS: any user that can read a file on an already-mounted (root-set-up) FUSE filesystem can be the victim that panics the kernel — but they do not control the overflow content.

So: real memory-safety defect, real panic/DoS, not an unpriv→root escalation on default DragonFly. It would become a real escalation primitive on a system where an unprivileged user can run a FUSE daemon (e.g. a setuid fusermount-style helper, or vfs.usermount+capability grants), at which point the attacker-controlled heap write would be a serious primitive.

5. The fix (validated)

fix.diff adds a consumer-side bound check in fuse_io_execute: if the daemon returned more bytes than the requested size (olen > bp->b_bcount), refuse the copy (treat as EINVAL) instead of overflowing. Minimal, targeted at the root cause; the unchecked memcpy can no longer execute.

This matches the spirit of the finding's proposal (clamp the reply len to the expected size and error out if exceeded). (The finding additionally suggests making fuse_audit_length authoritative by setting ohd->error = -EPROTO; that is a worthwhile defense-in-depth change at the protocol layer so all consumers are protected, but the consumer-side bound check alone fully closes this specific OOB write, so it is what I validated.)

Before / after (single-fix build)

• before — #0 + stock fuse.ko: oversized READ reply ⇒ memcpy OOB ⇒ panic: assertion "obj != NULL" … / trap 0xc in memcpy (3/3 runs).
• after — #1 (make -j6 nativekernel from patched /usr/src) + patched fuse.ko: oversized READ reply ⇒ bound check fires ⇒ bp->b_error = EINVAL, cat: /mnt/fuse/target: Invalid argument, no panic, guest stays up (3/3 runs).

fix_status = fixed.

6. PoC changes vs. the as-filed package

There was no prior PoC package for DF-0780 (the finding folder did not exist). I authored the entire evidence pack from scratch: evil_daemon.c (raw /dev/fuse malicious daemon), build.sh, run.sh, fix.diff, and this VERDICT.md + logs. The only iteration during testing was bumping REPLY_DATA_SIZE from 8192 → 131072: the buffer-cache read path uses cluster_readx, which on a sequential cat aggregates two 4 KiB blocks into one 8192-byte bp, so an 8192-byte reply fit exactly (no overflow); 131072 bytes guarantees the overflow regardless of cluster size.