DF-0912 — PoC

Claim: fuse_audit_length (sys/vfs/fuse/fuse_util.c:87-89) validates the daemon-CLAIMED ohd->len field instead of the actual reply buffer size (fb.len from fuse_buf_alloc(&fb, uio->uio_resid) in fuse_device_write). Two consequences:

1. Integer underflow at fuse_util.c:89: size_t len = ohd->len - sizeof(struct fuse_out_header); wraps to ~SIZE_MAX if a malicious daemon sets ohd->len < 16.
2. Three opcodes pass unconditionally — FUSE_FORGET (:96-98), FUSE_GETXATTR (:150-152), FUSE_LISTXATTR (:153-155) all hard-code res = true, so any claimed ohd->len (including an underflowed one) passes the audit for those opcodes.
3. The consumer fuse_ipc_tx (fuse_ipc.c:247) and per-opcode consumers use fuse_out_data_size(fip) = fip->reply.len - 16 (actual buffer) for their fixed-size struct dereferences, NOT ohd->len - 16. A daemon that claims the expected ohd->len while writing a short buffer therefore passes the audit and triggers a heap OOB read in the consumer (fuse_vfsops.c:fuse_statfs:399 reads 80 bytes from a 16-byte kmalloc).

This is the same root cause as DF-0895 and DF-0915; DF-0912 additionally calls out the integer underflow and the 3 unconditional-pass opcodes.

Build

cc -O2 -o fused_df0912 fused_df0912.c

Run (as root on the DragonFly guest)

kldload fuse                      # if not already loaded
./fused_df0912                    # OOB-read demo: short STATFS, claimed ohd->len=96
./fused_df0912 underflow          # underflow demo: claimed ohd->len=8 < 16

Expected output (bug present — unpatched #0 kernel)

• ./fused_df0912: statfs() succeeds; f_blocks/f_bfree/f_bavail/f_files/f_ffree contain non-zero kernel pointers (e.g. 0xfffff8004f... direct-map heap addresses and 0xffffffff82... kernel-image addresses) that vary byte-for-byte across iterations — proof of a kernel heap OOB read.
• ./fused_df0912 underflow: statfs() fails with EPROTO — the audit rejects the reply (the underflowed len=~SIZE_MAX fails the (len == 80) check for STATFS). This shows the underflow is real but, for size-checked opcodes, the size check still catches it; for the 3 unconditional-pass opcodes it would NOT be caught (but those are unreachable in this kernel — see VERDICT.md).

Expected output (FIXED kernel — single-fix fuse.ko)

• ./fused_df0912: statfs() returns all-zero fields; daemon's short write is rejected (write() returns -1, kernel logs EPROTO audit). No OOB read, no leak.
• ./fused_df0912 underflow: same EPROTO as before (now via the explicit actual_len < sizeof(fuse_out_header) guard in the fixed audit).

Threat model

FUSE is module-only on DragonFly; /dev/fuse is root:operator 0660 and the mount requires privilege, so the malicious daemon runs as root (consistent with DF-0780/0895/0915). Root→kernel is already game-over, but the primitive is a genuine kernel heap disclosure: any local user who can statfs() the mount point receives the leaked bytes (the audit bypass means a short reply whose claimed ohd->len matches the expected struct size passes silently).

DF-0912 — VERDICT

Verdict: REPRODUCED (kernel heap OOB read / info leak via FUSE audit trusting daemon-claimed ohd->len instead of actual buffer size). Fix: VALIDATED (single-module rebuild of fuse.ko closes the leak — clean before/after).

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 while setting ohd->len to the value the audit expects:

1. Daemon writes a 16-byte buffer (just the fuse_out_header), 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:188,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 would return only goes back to the daemon's write() syscall, not to the kernel-side consumer — and even that doesn't fire because the audit passed (the claimed len matched).

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 integer underflow (DF-0912 sub-claim #1)

At fuse_util.c:89, if a daemon sets ohd->len < 16 (e.g. ohd->len = 8), the subtraction ohd->len - sizeof(struct fuse_out_header) wraps the size_t to ~SIZE_MAX. The PoC's underflow mode demonstrates this:

• For size-checked opcodes (STATFS, INIT, etc.), the underflowed len still fails the len == sizeof(...) check, so the audit returns -1 and the daemon's write() gets EPROTO. BUT — critically — the IPC still completes regardless (fuse_device.c:218), ohd->error is left at 0, and the consumer (fuse_statfs) still proceeds to OOB-read 80 bytes past the 16-byte buffer. The PoC's underflow-mode output confirms statfs() succeeds and leaks the same kernel pointers (0xfffff8004f..., 0xffffffff82606ca0) as the OOB mode.

This proves the audit is advisory-only — even when it "catches" a malformed reply, the rejection only affects the daemon's write() return value; the kernel consumer is unaffected because ohd->error is never set by the audit-failure path.

• For the 3 unconditional-pass opcodes (below), the underflowed len would pass the audit regardless — but those opcodes are unreachable (see next section).

The 3 unconditional-pass opcodes (DF-0912 sub-claim #2) — dead code

The finding flags three opcodes where fuse_audit_length hard-codes res = true: - FUSE_FORGET (fuse_util.c:96-98) - FUSE_GETXATTR (fuse_util.c:150-152) - FUSE_LISTXATTR (fuse_util.c:153-155)

Reachability analysis (grep of sys/vfs/fuse/): - FUSE_FORGET: the kernel sends it via fuse_forget_node (fuse_util.c:71) using fuse_ipc_tx_noreply (fuse_util.c:74). No reply is ever read or audited — fuse_audit_length is never called on a FUSE_FORGET reply. The res = true is harmless dead code. - FUSE_GETXATTR / FUSE_LISTXATTR: there is no caller in the kernel — grep -rn 'FUSE_GETXATTR\|FUSE_LISTXATTR' sys/vfs/fuse/ finds them only in fuse_audit_length's switch and fuse_get_ops's name table, never in a fuse_ipc_fill(.., FUSE_GETXATTR, ..). These opcodes are never issued, so their replies are never audited.

Conclusion on the 3 opcodes: they are defense-in-depth gaps (the res = true is arguably correct for GETXATTR/LISTXATTR since their replies are variable-length and the consumer uses fuse_out_data_size(fip) to bound the read; and harmless for FORGET since no reply exists). The live, exploitable primitive is the OOB read via claimed-len mismatch on the reachable opcodes (INIT/STATFS/STATVFS and others).

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

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

[OOB run1 iter0] f_blocks=0xfffff8004f0a25c0  f_bavail=0xfffff8004f0a25d0  f_ffree=0xfffff8004f0a2610
[OOB run1 iter1] f_blocks=0xfffff8004f0a25d0  f_bavail=0xfffff8004f0a2610  f_ffree=0xfffff8004f0a2570
[OOB run2 iter0] f_blocks=0xfffff8004f0a25d0  f_bavail=0x68732e646c697562 ("build/sh..")  f_ffree=0xfffff8004f0a2540
[OOB run3 iter1] f_blocks=0x2b6364747362696c ("listdtc+")  f_bavail=0x66645f6465737566 ("fused_df")  f_ffree=0x706172772d6f746c
[underflow iter0] f_bavail=0xfffff8004f3301e0  f_files=0xffffffff82606ca0  (audit rejected write but consumer STILL read OOB)

• 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).
• ASCII strings ("fused_df", "build/sh", "listdtc+") — leaked from adjacent slab chunks containing the daemon's own binary/path strings.
• 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.

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 per this bug). Per the valid-hard-blocker rule for read-only primitives, there is no escalation chain to develop. The realistic impact ceiling is a kernel heap info leak / KASLR defeat: the bytes leaked are adjacent slab-chunk contents (kernel pointers and slab metadata); any local user who can statfs() the mount receives them. (The daemon is already root per the FUSE threat model, but the primitive's value is the kernel-pointer disclosure to other users who can statfs() the mount — the audit bypass means a short reply whose claimed ohd->len matches the expected struct size passes silently.)

PoC changes

• Authored fused_df0912.c from scratch (no prior PoC existed for DF-0912): a fork-based malicious FUSE daemon (parent = /dev/fuse I/O loop; child = mount + statfs() ×3).
• Default mode: valid INIT, short STATFS with claimed ohd->len=96 → OOB read (audit bypass via claimed-len match).
• underflow mode: short STATFS with claimed ohd->len=8 (< 16) → demonstrates the size_t underflow AND that the audit's "rejection" is advisory-only (consumer still reads OOB).
• 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 ("add bufsize param validate ohd->len<=bufsize"). The implemented fix.diff (shared with DF-0895, same root cause) 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; — directly addresses the DF-0912 integer-underflow concern.
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(). This fixes the advisory-only nature of the audit (the consumer no longer proceeds when the audit fails).
3. fuse.h — updated prototype.

This matches the DF-0895 root-cause fix (same bug, same code path, same three files). It 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, and makes the previously-advisory audit actually reject malformed replies.

Fix validation (Phase 8)

• Baseline (#0 kernel, unpatched fuse.ko sha 680333bb...): leak reproduced — kernel pointers and ASCII strings in statfs() output (above). Both OOB mode and underflow mode leak.
• Patched (rebuilt fuse.ko sha 45031678..., 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 in both OOB and underflow modes; f_iosize = 0 (vs 4096 on baseline) confirms fuse_statfs returns early before reading fuse_out_data(fip); the daemon's short write is rejected (actual_write=-1). Guest stays up. No OOB read, no leak. Fix is deterministic (3/3 clean in OOB mode, 3/3 clean in underflow mode).

Kernel references confirmed during verification: - sys/vfs/fuse/fuse_util.c:87-89 (audit uses ohd->len — the bug; underflow site) - sys/vfs/fuse/fuse_util.c:96-98 (FUSE_FORGET res=true — dead code, no reply) - sys/vfs/fuse/fuse_util.c:138-140 (FUSE_STATFS size check — bypassed via claimed len) - sys/vfs/fuse/fuse_util.c:150-155 (FUSE_GETXATTR/LISTXATTR res=true — dead code, no caller) - sys/vfs/fuse/fuse_device.c:182 (fuse_buf_alloc(&fb, uio->uio_resid) — actual buffer size) - sys/vfs/fuse/fuse_device.c:205 (fip->reply = fb — stores actual-size buffer) - 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 == 0) - 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) — OOB read site) - sys/vfs/fuse/fuse_vfsops.c:430 (STATVFS fso = fuse_out_data(fip))