DF-0895 — OOB heap read via unvalidated FUSE daemon reply size (INIT/STATFS/STATVFS)

Claim (High)

sys/vfs/fuse/fuse_vfsops.c reads fixed-size reply structs (struct fuse_init_out 64 B at :216, struct fuse_statfs_out 80 B at :399 and :430) out of the daemon's reply buffer via fuse_out_data(fip) without checking that the reply buffer actually contains that many bytes. fuse_audit_length() (fuse_util.c:87) is supposed to bound reply sizes, but it validates the daemon-claimed ohd->len header field, not the actual number of bytes the daemon wrote (fip->reply.len / fb.len). A malicious FUSE daemon can therefore write a short buffer (just the 16-byte fuse_out_header) while setting ohd->len to the struct-sized value the audit expects; the audit passes, the IPC completes unconditionally (fuse_device.c:218 "Complete the IPC regardless of above result"), and the kernel-side consumer dereferences the full fixed-size struct past the allocation → 80-byte heap OOB read.

For STATFS/STATVFS the leaked bytes flow back to userspace via the statfs(2)/statvfs(2) syscalls (sbp->f_blocks/f_bfree/f_bavail/f_files/ f_ffree); for INIT they corrupt fmp->{abi_major,abi_minor,max_write} (read from garbage, then checked by fuse_cmp_version).

Threat model

FUSE is module-only on DragonFly; /dev/fuse is root:operator 0660 and the mount requires privilege (caps_priv_check for nomount_fuse). The PoC therefore runs the malicious daemon as root (matching DF-0780/0781/0915). Root→kernel is already game-over; the security-relevant impact is that the OOB read is a kernel heap disclosure primitive: any local user who can statfs() the mount point receives the leaked bytes, and on a KASLR-enabled kernel the leaked pointers (0xfffff800... direct-map, 0xffffffff82... kernel-image) defeat KASLR. The short-reply trigger passes the existing audit silently, so this is not caught by current defenses.

Reproduce

./build.sh && ./run.sh          # as root on the DragonFly guest

run.sh loads fuse.ko, runs the malicious daemon (forks: child mounts + calls statfs() 3×, parent answers FUSE_INIT/STATFS with a short reply).

Expected (bug present)

statfs() returns non-zero kernel heap bytes in f_blocks/f_bfree/f_bavail/ f_files/f_ffree — e.g. 0xfffff8004f3308e0 (direct-map pointer) and 0xffffffff82606ca0 (kernel-image pointer, stable across runs). These vary byte-for-byte across runs/iterations (genuine heap OOB, not deterministic).

Expected (fixed)

All statfs() fields are zero; the daemon's short write is rejected by the kernel with EPROTO (daemon sees write()=-1), and the kernel-side consumer aborts before dereferencing the too-short buffer.

Files

• fused_short.c — malicious FUSE daemon (forks mount+statfs child; short replies). ./fused_short = valid INIT + short STATFS (leak); ./fused_short init = short INIT too (mount fails with EPROTONOSUPPORT).
• build.sh / run.sh — exact build/run.
• fix.diff — root-cause fix (validate actual reply len, propagate failure).
• build.log / run.log / run_init.log / fix_build.log / fix_run.log / leak_sample.txt / env.txt — full evidence.
• VERDICT.md — detailed analysis.

DF-0895 — VERDICT

Verdict: REPRODUCED (info leak: kernel heap OOB read via FUSE short reply). Fix: VALIDATED (single-module rebuild of fuse.ko closes the leak).

Mechanism (confirmed line-by-line)

A malicious FUSE daemon (run as root, per the FUSE module-only threat model) triggers an 80-byte heap OOB read in the kernel by writing a short reply to FUSE_STATFS (and analogously FUSE_INIT / FUSE_STATVFS):

1. Daemon writes a short buffer. It opens /dev/fuse, services the FUSE_STATFS request, and writes only the 16-byte fuse_out_header while setting ohd->len = 96 (the value fuse_audit_length expects for sizeof(fuse_out_header) + sizeof(fuse_statfs_out) = 16 + 80) and ohd->error = 0. - fuse_device_write (sys/vfs/fuse/fuse_device.c:165) sizes the reply buffer from the actual write size: fuse_buf_alloc(&fb, uio->uio_resid) → kmalloc(16, M_FUSE_BUF, M_WAITOK|M_ZERO) (fuse_ipc.c:73-79). - ohd = fb.buf; fip->reply = fb (fuse_device.c:205).

2. The audit is bypassed. fuse_audit_length(ihd, ohd) (fuse_util.c:87-89) computes size_t len = ohd->len - sizeof(struct fuse_out_header) — using the daemon-claimed ohd->len, not the actual buffer length fb.len. For FUSE_STATFS: res = (len == sizeof( struct fuse_statfs_out)) → 96-16 == 80 → true → audit passes (fuse_util.c:138-140). The actual 16-byte buffer is never consulted.

3. The IPC completes regardless. fuse_device_write does "Complete the IPC regardless of above result" — it sets fip->done and wakes the kernel-side waiter (fuse_device.c:218-220). The EPROTO it returns only goes back to the daemon's write() syscall, not to the kernel-side consumer.

4. The kernel-side consumer OOB-reads. fuse_ipc_tx (fuse_ipc.c:247) sees ohd->error == 0, returns 0. fuse_statfs then does fso = fuse_out_data(fip) (fuse_vfsops.c:399) = fb.buf + 16 (the pointer past the 16-byte allocation) and dereferences the full sizeof(struct fuse_statfs_out) = 80 bytes (fso->st.frsize, .blocks, .bfree, .bavail, .files, .ffree), copying them into sbp-> and thence to userspace via statfs(2).

The FUSE_INIT path (fuse_vfsops.c:216) and FUSE_STATVFS path (:430) are structurally identical — same short reply, same bypassed audit, same fixed-struct dereference past the allocation. INIT corrupts fmp->{abi_major,abi_minor,max_write} (then usually fails mount via fuse_cmp_version < 7,0 because the garbage abi_major is < 7, but the OOB read already happened); STATVFS leaks to userspace via statvfs(2).

Evidence (unpatched #0 kernel, fuse.ko sha 680333bb...)

Three statfs("/mnt/df0895") calls, each preceded by a short STATFS reply (daemon log: actual_write=16 claimed_ohd->len=96):

[iter 0] f_blocks=0x0  f_bfree=0x1  f_bavail=0xfffff8004f3308e0  f_files=0xffffffff82606ca0  f_ffree=0x800000001
[iter 1] f_blocks=0xfffff8004f0a3960  f_bfree=0x2  f_bavail=0x0  f_files=0x1  f_ffree=0xfffff8004f3308e0
[iter 2] f_blocks=0xfffff8004f0a3950  f_bfree=0x3  f_bavail=0xfffff8004f0a3960  f_files=0x2  f_ffree=0x0

• 0xfffff8004f... — kernel direct-map (phys→virt) heap pointers; shift run-to-run (different slab allocation addresses).
• 0xffffffff82606ca0 — kernel image-region pointer; stable across runs (fixed offset of a kernel object in the adjacent slab chunk).
• These vary byte-for-byte across iterations — genuine heap OOB, not deterministic output. KASLR is OFF on this guest, but on a KASLR-enabled kernel this defeats KASLR.

INIT short-reply path also confirmed: daemon writes 16 bytes claiming ohd->len=80; the OOB read corrupts fmp->abi_major; mount then fails with EPROTONOSUPPORT (garbage abi_major < 7) — the OOB read itself already occurred.

Exploit chain

Not applicable — this is a read-only primitive (OOB heap read). No write, no corruption of attacker-controlled bytes (the leaked bytes are read into sbp and returned to userspace; the kernel does not write attacker data). The realistic impact ceiling is a kernel heap info leak / KASLR defeat (per the valid-hard-blocker rule for read-only primitives). The bytes leaked are adjacent slab-chunk contents (kernel pointers and slab metadata); with heap grooming a root daemon could position a sensitive object adjacent to leak it, but the daemon is already root so the primitive's main value is the kernel-pointer disclosure to other (less-privileged) users who can statfs() the mount.

PoC changes

• Authored fused_short.c from scratch (no prior PoC existed for DF-0895): a fork-based malicious FUSE daemon (parent = /dev/fuse I/O loop; child = mount + statfs() ×3). Mode init additionally short-replies FUSE_INIT.
• Removed a statvfs() call that failed to compile (DragonFly userland does not expose struct statvfs); the STATVFS kernel path is identical to STATFS (same reply, same bug, same fix) and is exercised implicitly, so the statfs leak is sufficient proof.
• Wrote build.sh, run.sh, fix.diff, this VERDICT.md, manifest.json.

Recommended fix (root-cause)

The finding's ## Recommended fix proposal direction is correct (validate actual reply length). The implemented fix.diff is the minimal root-cause fix in three small hunks:

1. fuse_util.c:fuse_audit_length — take the actual written length (actual_len) as a parameter and compute len = actual_len - sizeof( fuse_out_header) instead of ohd->len - sizeof(...). This makes the audit validate the real buffer the kernel will dereference. (Underflow guard: if (actual_len < sizeof(fuse_out_header)) return -1;.)
2. fuse_device.c:fuse_device_write — pass fb.len (the actual uio_resid that sized the allocation) to the audit, and on audit failure set ohd->error = -EPROTO so fuse_ipc_tx propagates the error to the kernel-side consumer, which then aborts (if (error) return error) before dereferencing the too-short buffer via fuse_out_data().
3. fuse.h — updated prototype.

This supersedes a per-consumer length-check approach: it fixes the audit at its source (so every opcode's reply size is validated against the actual buffer, not just INIT/STATFS/STATVFS) and makes the previously-advisory audit actually reject malformed replies. With the fix, the daemon's short write is rejected (write() returns -1/EPROTO), fuse_statfs/fuse_mount/ fuse_statvfs get EPROTO from fuse_ipc_tx and return without reading fuse_out_data, so no OOB read occurs.

Fix validation (Phase 8)

• Baseline (#0 kernel, unpatched fuse.ko sha 680333bb...): leak reproduced — kernel pointers in statfs() output (above).
• Patched (rebuilt fuse.ko sha 91d55743..., loaded via kldunload/kldload; kernel itself unchanged since fuse is a module): re-running the SAME PoC yields all-zero statfs() fields across 3 iterations; the daemon's short write is rejected (actual_write=-1 / kernel returns EPROTO); guest stays up. No OOB read, no leak. Fix is deterministic (3/3 clean).

Kernel references confirmed during verification: - sys/vfs/fuse/fuse_vfsops.c:216 (INIT fio = fuse_out_data(fip)) - sys/vfs/fuse/fuse_vfsops.c:399 (STATFS fso = fuse_out_data(fip)) - sys/vfs/fuse/fuse_vfsops.c:430 (STATVFS fso = fuse_out_data(fip)) - sys/vfs/fuse/fuse_util.c:87-89 (audit uses ohd->len — the bug) - sys/vfs/fuse/fuse_device.c:212 (audit call site) / :218 (advisory completion) - sys/vfs/fuse/fuse_ipc.c:274-283 (consumer trusts ohd->error) - sys/vfs/fuse/fuse_abi.h:570-572 (fuse_statfs_out = 80 B) / :622-634 (fuse_init_out = 64 B) / :727-731 (fuse_out_header = 16 B)