DF-0781 — Kernel heap info leak via unvalidated namelen in fuse_vop_readdir

Reproduction + fix-validation evidence pack.

What this proves

fuse_vop_readdir() (sys/vfs/fuse/fuse_vnops.c:1012) walks a FUSE daemon's FUSE_READDIR reply as a sequence of struct fuse_dirent. Its only bounds check is len < FUSE_NAME_OFFSET (24) — it never validates that fde->namelen fits in the remaining reply. It then passes the daemon-chosen fde->namelen (truncated to uint16 d_namlen) and fde->name to vop_write_dirent(), which does bcopy(d_name, dp->d_name, d_namlen) reading d_namlen bytes from fde->name regardless of how many name bytes actually exist in the reply. When d_namlen exceeds the real name size, the bcopy reads past the daemon's kmalloc'd M_FUSE_BUF reply buffer into adjacent kernel heap, and uiomove then ships those bytes to the user's getdents buffer — a kernel heap info leak.

After the leak, len -= freclen underflows (both size_t) and buf += freclen advances to a wild pointer — the "wild ptr" half of the title. Whether the next iteration faults depends on slab layout; on this INVARIANTS-ON guest with fde->namelen = 32000 it did not fault (mapped slab) so the guest survived, but on a system with a different slab layout it would page-fault → panic (DoS).

The existing fuse_audit_length() in fuse_device_write() only checks len <= fri->size for FUSE_READDIR (fuse_util.c:132, where fri->size = FUSE_BLKSIZE * 10 = 40960) — it does NOT validate dirent.namelen against the actual reply content, so the audit passes and the IPC completes normally.

Files

• evil_daemon.c — raw /dev/fuse malicious daemon. Mounts a synthetic FUSE fs (/mnt/fuse) and answers every FUSE_READDIR with a single 48-byte reply containing one dirent with namelen = 32000 but only 8 actual name bytes.
• read_trigger.c — unprivileged getdents consumer. Pre-fills its 64 KB buffer with 0x5a, calls getdents(2), then analyzes the buffer to prove the OOB read (kernel-touch high-water mark, honored d_namlen, non-zero leaked-byte count, kernel-pointer scan, leaked- window hexdump).
• build.sh — cc -O0 -g -o evil_daemon evil_daemon.c && cc -O0 -g -o read_trigger read_trigger.c
• run.sh — loads fuse, starts the daemon (root), then runs the getdents trigger as maxx.
• fix.diff — consumer-side bound check in fuse_vop_readdir (fde->namelen > NAME_MAX || FUSE_NAME_OFFSET + fde->namelen > len || freclen > len → EINVAL).
• build.log / run.log / fix_run.log / fix_build.log / leak_sample.txt / env.txt / VERDICT.md / manifest.json.

Reproduce (info leak)

On the audit guest (unprivileged maxx exists; root needed only to load the module, open /dev/fuse, and call mount -t 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
kldload /root/fuse.ko
# as maxx:
cd poc/DF-0781 && sh build.sh
# as root:
sh run.sh            # maxx getdents /mnt/fuse -> leak fires

Expected on the unpatched kernel + stock fuse.ko:

=== kernel wrote through user-buffer offset 32023 ===
=== honored d_namlen = 32000 (daemon claimed 32000) ===
=== 72 non-zero non-marker bytes in window [24..32024) ===
[LEAK-PROOF] kernel wrote 32024 bytes; ... => 32000 bytes were read from past the daemon's reply buffer

with kernel pointers (0xfffff8008d62XXXX) and ASCII kernel strings (rcng_dhcpd\0disabled, rcng_lvm, rcng_cryptdisks, rcng_initrandom, rcng_fsck, running, disabled) visible in the leaked window.

Validate the fix

Because fuse is a loadable module (not compiled into X86_64_GENERIC), the fix lives in fuse.ko. Build the patched module, install, reload, re-run:

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 /usr/obj/usr/src/sys/vfs/fuse/fuse.ko /root/fuse.ko'
vm.sh run_root 'kldunload fuse; kldload /root/fuse.ko'
sh run.sh           # maxx getdents -> EINVAL, NO leak, guest up

Expected on the patched fuse.ko: the bound check fires, the dirent is rejected, and the user buffer's 0x5a marker is fully preserved:

=== kernel wrote through user-buffer offset -1 (bytes [0..-1]) ===
=== kernel did not write a full dirent header -> no leak ===

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

The trigger is root-only on default DragonFly (kldload fuse + /dev/fuse root:operator 0660 + mount -t fuse capability check all require root), so the daemon author must be root or operator+helper. The readdir consumer (the user whose getdents trips the leak) can be unprivileged (maxx here). This is a root-controlled malicious daemon → kernel info leak → unprivileged consumer threat model — a hardening gap / insider-abuse vector on a default system, and a real info leak where unprivileged users are permitted to mount FUSE. It is not an unprivileged→root escalation on a default system.

DF-0781 — Verdict

Kernel heap info leak via unvalidated namelen in fuse_vop_readdir (+ adjacent len -= freclen underflow → wild pointer deref)

Verdict: REPRODUCED (kernel heap info leak); fix VALIDATED

The "wild ptr" / panic variant named in the title is also reachable (the loop's len -= freclen underflows and buf is advanced past the reply buffer), but on this INVARIANTS-ON with-src guest iteration-2 deref landed in mapped slab memory and did not fault in the runs observed — so the primary reproduced impact is the info leak, not panic.

1. The bug — confirmed at source and at runtime

fuse_vop_readdir() (sys/vfs/fuse/fuse_vnops.c:1012) parses the daemon's FUSE_READDIR reply buffer as a sequence of struct fuse_dirent records:

/* fuse_vnops.c:1057-1091 */
while (1) {
    if (len < FUSE_NAME_OFFSET) {            /* 24-byte header only   */
        ...
        break;
    }
    ...
    fde = (const struct fuse_dirent*)buf;
    if (!fde->namelen) { error = EINVAL; break; }
    freclen = FUSE_DIRENT_SIZE(fde);         /* = ALIGN(24 + namelen) */

    /* MISSING: any check that namelen (or freclen) fits in `len`. */

    if (cur_offset >= uio->uio_offset) {
        error = 0;
        if (vop_write_dirent(&error, uio, fde->ino, fde->type,
            fde->namelen, fde->name))        /* passes daemon namelen  */
            break;                            /* and fde->name pointer  */
        ...
    }

    cur_offset += _DIRENT_RECLEN(fde->namelen);
    buf += freclen;
    len -= freclen;                           /* underflows if freclen>len */
}

The guard at line 1058 only checks len < FUSE_NAME_OFFSET (24) — it ensures the 24-byte dirent header fits, but never that FUSE_NAME_OFFSET + namelen <= len. fde->namelen is the daemon-chosen uint32 from the reply; it is then passed unvalidated as d_namlen (truncated to uint16) to vop_write_dirent(), which does:

/* sys/kern/vfs_subr.c:2560 */
int vop_write_dirent(int *error, struct uio *uio, ino_t d_ino,
        uint8_t d_type, uint16_t d_namlen, const char *d_name)
{
    struct dirent *dp;
    size_t len;
    len = _DIRENT_RECLEN(d_namlen);
    if (len > uio->uio_resid)
        return(1);
    dp = kmalloc(len, M_TEMP, M_WAITOK | M_ZERO);
    dp->d_ino = d_ino;
    dp->d_namlen = d_namlen;
    dp->d_type = d_type;
    bcopy(d_name, dp->d_name, d_namlen);     /* <-- reads d_namlen bytes
                                              * from d_name (= fde->name)
                                              * with NO bound vs the
                                              * daemon reply buffer */
    *error = uiomove((caddr_t)dp, len, uio); /* <-- leaks to userspace */
    ...
}

So a daemon that replies with a small payload but a large namelen makes the kernel bcopy namelen bytes from fde->name (a pointer into the kmalloc'd M_FUSE_BUF reply buffer), reading namelen - actual_name_bytes bytes past the reply buffer into adjacent kernel heap, then uiomove those bytes into the user's getdents buffer. The existing fuse_audit_length() in fuse_device_write() does NOT catch this: for FUSE_READDIR it only checks len <= fri->size (fuse_util.c:132), where fri->size = FUSE_BLKSIZE * 10 = 40960 — so any reply up to 40 960 bytes passes audit regardless of how its dirent namelen fields lie about the actual content.

After the first iteration, len -= freclen underflows when freclen > len (both size_t, unsigned), and buf += freclen advances buf past the reply buffer. The next iteration then dereferences a wild pointer — the "wild ptr" half of the title. Whether that deref faults depends on the slab layout (on the default INVARIANTS-ON guest with fde->namelen = 32000, the wild deref landed in mapped slab memory in the runs observed, so the guest survived but getdents returned EINVAL from the post-leak iteration's fde->namelen == 0 check).

2. Live reproduction — structural proof + leaked kernel content

evil_daemon.c is a raw /dev/fuse protocol daemon that opens /dev/fuse, mounts a synthetic FUSE filesystem at /mnt/fuse, and answers every FUSE_READDIR with a single 48-byte reply:

fuse_out_header.len = 48 (16 header + 32 data)
fuse_dirent { ino=2, off=0, namelen=32000, type=DT_REG }
fuse_dirent.name[] = "ABCDEFGH"   /* only 8 actual bytes */

I.e. the daemon claims namelen=32000 but only emits 8 bytes of name. read_trigger.c is an unprivileged consumer that opens the mountpoint and calls getdents(fd, buf, 65536) with a 64 KB buffer pre-filled with 0x5a markers.

Result on the unpatched #0 kernel + stock fuse.ko (deterministic):

[trigger] getdents returned -1 (errno 22: Invalid argument)
=== kernel wrote through user-buffer offset 32023 (bytes [0..32023]) ===
=== expected write size if namelen=32000 honored: _DIRENT_RECLEN(32000) = 32016 bytes ===
=== honored d_namlen = 32000 (daemon claimed 32000) ===
=== 72 non-zero non-marker bytes in window [24..32024) (past the 8-byte real name) ===
[LEAK-PROOF] kernel wrote 32024 bytes; d_namlen honored = 32000;
             real name bytes from daemon = 8;
             => 32000 bytes were read from past the daemon's reply buffer

The kernel wrote 32 024 bytes to the user buffer (one full _DIRENT_RECLEN(32000) dirent + 8 bytes of the next iteration's partial header), honoring the daemon's d_namlen = 32000 even though the daemon only sent 8 bytes of name. 31 992 bytes were read from past the daemon's reply buffer = out-of-bounds read = info leak.

The leaked bytes vary run-to-run as the slab accumulates state. After a few warm-up getdents calls (which leave stale M_FUSE_BUF slab content), the leaked window contains recognizable kernel data:

=== leaked window hexdump (first 256 bytes past real name) ===
a821628d00f8ffff 0800000000000000 0200000000000000 0000000000000000
007d000008000000 4142434445464748 010000000a000000 7023628d00f8ffff
7b23628d00f8ffff 72636e675f646863 7064006469736162 6c65640000000000
8820628d00f8ffff 1400000000000000 0200000000000000 ...

Decoded (little-endian):

Across 5 consecutive runs (same mount) the non-zero leaked-byte count varied: 281, 366, 385, 404, 0, 262, 72, 796 — confirming the leak content is genuine heap residue (varies with slab state), not deterministic zero-fill. Earlier runs also caught rcng_lvm, rcng_cryptdisks, rcng_initrandom, rcng_fsck, rcng_dhcpd, running, disabled and many 0xfffff8008d62XXXX kernel pointers — see leak_sample.txt.

3. Primitive characterization

• what the attacker controls: fde->namelen (uint32, daemon-chosen; effectively uint16 after truncation in vop_write_dirent). Controls how many bytes the kernel reads past the daemon's reply buffer.
• what the attacker does NOT control: the content of the leaked bytes (those are adjacent slab heap — kernel pointers, kernel strings, refcounts, etc. — depending on what's been allocated/freed nearby).
• read size: up to ~65 535 bytes per call (limited by uint16 d_namlen and the user's getdents buffer size). Repeatable per call.
• impact: kernel heap info leak. Concrete leaked content observed includes kernel virtual addresses in the 0xfffff800... KVA range (useful for KASLR-defeat — though this guest has KASLR off; on a real KASLR-enabled system these leaked pointers would defeat it) and kernel ASCII strings revealing internal service names.
• secondary effect: after the leak, len -= freclen underflows and buf += freclen advances to a wild pointer. Whether the next iteration's (struct fuse_dirent*)buf deref faults depends on slab layout. On this guest (INVARIANTS ON, fde->namelen=32000) it did not fault (slab was mapped); on a system where the wild pointer reaches unmapped KVA it would page-fault → panic (DoS).

4. Exploit chain to uid=0 — NOT APPLICABLE (read-only primitive)

Per Phase 6, escalation only applies to write-capable primitives. The primary reproduced impact here is a read-only OOB read — there is no write, no corruption of any kernel object, no UAF, no function-pointer clobber. bcopy(d_name, dp->d_name, d_namlen) reads FROM the daemon buffer (the OOB source) and writes INTO a freshly kmalloc'd dp (M_TEMP, sized exactly to _DIRENT_RECLEN(d_namlen)), then uiomove copies that dp out to userspace. No kernel object is overwritten by attacker bytes. Therefore there is no escalation chain to develop; the realistic impact ceiling is the info leak itself (KASLR defeat, kernel pointer disclosure, internal-string disclosure).

A separate threat-model caveat applies regardless: the trigger is root-only on default DragonFly (the FUSE module must be kldload'd, /dev/fuse is root:operator 0660, and mount -t fuse requires caps_priv_check(SYSCAP_NOMOUNT_FUSE)). So the daemon author must be root (or operator + a mount-helper); the readdir consumer (the user whose getdents triggers the leak) can be unprivileged (maxx here). This is a root-controlled malicious daemon → kernel info leak → unprivileged consumer threat model — i.e. a hardening gap / insider- abuse vector on a default system, becoming a real info leak where unprivileged users are permitted to mount FUSE (setuid fusermount-style helper, or vfs.usermount+capability grants).

5. The fix (validated)

fix.diff adds three consumer-side bound checks in fuse_vop_readdir right after computing freclen, before the dirent is honored:

/*
 * DF-0781: a malicious/buggy daemon may claim a name length that
 * exceeds the remaining reply buffer (or is absurdly large).
 * ...
 */
if (fde->namelen > NAME_MAX ||
    FUSE_NAME_OFFSET + fde->namelen > len ||
    freclen > len) {
    error = EINVAL;
    break;
}

These reject any dirent whose name does not fit in the remaining reply buffer (closing the OOB read), whose claimed name exceeds the BSD filename limit (NAME_MAX = 255, sys/sys/syslimits.h:54), or whose aligned record length would underflow len (closing the wild-pointer path). Minimal and targeted at the root cause; the unchecked bcopy and len -= freclen can no longer execute with an out-of-range namelen.

This matches the spirit of the finding markdown's ## Recommended fix proposal (if (namelen > FUSE_NAME_MAX || FUSE_NAME_OFFSET + namelen > len || freclen > len) error = EINVAL break). The only substitution is NAME_MAX (a universally-defined sys/sys/syslimits.h constant, value 255) for the not-defined-in-tree FUSE_NAME_MAX — semantically identical.

Before / after (single-fix build)

Because fuse is a loadable module (optional fuse in sys/conf/files, NOT compiled into X86_64_GENERIC), the fix lives in fuse.ko. The validation builds just the patched fuse.ko from /usr/src/sys/vfs/fuse, installs it, reloads, and re-runs the same PoC.

• before — #0 kernel + stock fuse.ko (size 0xa9000): === kernel wrote through user-buffer offset 32023 === === honored d_namlen = 32000 (daemon claimed 32000) === === 72 non-zero non-marker bytes in window [24..32024) === [LEAK-PROOF] kernel wrote 32024 bytes; ... => 32000 bytes were read from past the daemon's reply buffer with leaked kernel pointers (0xfffff8008d622XXX) and ASCII kernel strings (rcng_dhcpd\0disabled) visible in the buffer.

• after — #0 kernel + patched fuse.ko (size 0xd000, sha256 9f19b420...e7a11a, built from /usr/src/sys/vfs/fuse with -Werror): bound check fires, dirent rejected before any bcopy / uiomove: [trigger] getdents returned -1 (errno 22: Invalid argument) === kernel wrote through user-buffer offset -1 (bytes [0..-1]) === === kernel did not write a full dirent header -> no leak === 3/3 deterministic patched runs wrote zero bytes (the user buffer's 0x5a marker is fully preserved — no kernel data touched it).

fix_status = fixed.

6. PoC changes vs. the as-filed package

There was no prior PoC package for DF-0781 (the finding folder did not exist; only the DB row was present). I authored the entire evidence pack from scratch:

• evil_daemon.c — raw /dev/fuse malicious daemon; replies to FUSE_READDIR with dirent.namelen = 32000 but only 8 real name bytes. Modelled on the DF-0780 daemon (same threat model).
• read_trigger.c — unprivileged getdents consumer that pre-fills its buffer with 0x5a, calls getdents(2), and analyzes the buffer to prove the OOB read (high-water mark of kernel-touched bytes, honored d_namlen, non-zero leaked-byte count, kernel-pointer scan, leaked-window hexdump).
• build.sh / run.sh — exact, runnable build and run scripts.
• fix.diff — consumer-side bound check (fde->namelen > NAME_MAX || FUSE_NAME_OFFSET + fde->namelen > len || freclen > len) in fuse_vop_readdir.
• VERDICT.md (this file), manifest.json, and the full untrimmed logs.

The only iterations during testing were: 1. fde->namelen was bumped from 600 → 32000 to ensure _DIRENT_RECLEN fit comfortably in the 64 KB getdents buffer and to traverse more slab chunks (maximizing the chance of catching non-zero leaked bytes). 2. The read_trigger initially used a hand-rolled inline-asm syscall stub; this returned a confusing n=22 (the syscall convention differs from what I'd assumed). Switching to the libc getdents() wrapper fixed it. 3. The kernel-pointer detector was broadened from 0xffffffff... only to also recognize 0xfffff8XX... (the actual KVA range of the leaked pointers).