DF-0009 — PoC

leak_vfsconf.c — unprivileged leak of kernel .data pointers via the VFS_CONF (vfs.generic) sysctl.

Verdict

REPRODUCED on DragonFly master DEV (v6.5.0.1712.g89e6a-DEVELOPMENT, 2026-06-29). As the unprivileged maxx user (uid 1001, not in wheel), the PoC dumps all 11 filesystem-type struct vfsconf records. Each leaks two kernel .data pointers — vfc_vfsops (the per-filesystem ops vector) and vfc_next (the vfsconf list link) — 11 + 10 raw kernel addresses total. Every vfc_vfsops value matches an exact symbol in nm /boot/kernel/kernel (e.g. devfs_vfsops=0xffffffff81111ae0, hammer_vfsops=0xffffffff81112000, tmpfs_vfsops=0xffffffff81117200). Byte-identical across 3 runs → deterministic, reliable KASLR-defeat. See VERDICT.md for the full line-by-line trace and the evidence table.

The issue

vfs_sysctl()'s VFS_CONF handler (sys/kern/vfs_subr.c:1845) copies the whole struct vfsconf to userspace:

return (SYSCTL_OUT(req, vfsp, sizeof *vfsp));   /* :1845 whole struct */

struct vfsconf (sys/sys/mount.h:477-484) embeds struct vfsops *vfc_vfsops (kernel .data ops vector) and STAILQ_ENTRY(vfsconf) vfc_next (kernel .data list pointer). The vfs.generic node is CTLFLAG_RD with no privilege gate (vfs_subr.c:1850), and sysctl reads are not privilege-gated, so any unprivileged local user can dump these addresses — a reliable KASLR-bypass primitive. The legacy ovfsconf path (sysctl_ovfs_conf_iter, :1863) copies vfc_vfsops verbatim too.

Build

./build.sh        # cc -o leak_vfsconf leak_vfsconf.c

Run (as an UNPRIVILEGED user)

./run.sh          # ./leak_vfsconf

Expected output (bug present)

sizeof(struct vfsconf) = 48
type 1  hammer      vfc_vfsops=0xffffffff81112000  vfc_next=0xffffffff8110fa40
type 2  mfs         vfc_vfsops=0xffffffff8110fa80  vfc_next=0xffffffff810ebb40
...
type 11 tmpfs       vfc_vfsops=0xffffffff81117200  vfc_next=0x0

filesystem types dumped: 11
kernel .text pointers leaked (vfc_vfsops): 11
kernel .data pointers leaked (vfc_next)  : 10
result: LEAK CONFIRMED (KASLR-defeat primitive)

On a fixed kernel the printed vfc_vfsops/vfc_next would be 0x0 and the PoC exits 2 (no kernel pointers observed).

Impact

Information disclosure only (kernel .data addresses, not memory contents). Standalone impact is Low, but it is a prerequisite primitive for exploiting any future local kernel memory-corruption bug (KASLR defeat / gadget relocation). Reachable by any unprivileged local user on a default kernel; no config.

DF-0009 — VFS_CONF (vfs.generic) sysctl leaks kernel pointers to unprivileged users

Verdict

REPRODUCED — deterministic, unprivileged disclosure of kernel .data addresses (the per-filesystem struct vfsops instances and the vfsconf linked-list pointers) via the VFS_CONF sysctl handler. 11 filesystem types → 11 distinct kernel .data pointers leaked on every run, byte-identical across runs, every one confirmed against nm /boot/kernel/kernel. This is a reliable KASLR-defeat / pointer-disclosure primitive, reachable by any local user with no privileges and no special setup.

The bug — confirmed line-by-line

vfs_sysctl() (sys/kern/vfs_subr.c:1839-1845):

case VFS_CONF:
    if (namelen != 3)
        return (ENOTDIR);                 /* :1841 overloaded            */
    vfsp = vfsconf_find_by_typenum(name[2]);
    if (vfsp == NULL)
        return (EOPNOTSUPP);              /* :1844                       */
    return (SYSCTL_OUT(req, vfsp, sizeof *vfsp));   /* :1845 whole struct */

SYSCTL_OUT(req, vfsp, sizeof *vfsp) copies the entire struct vfsconf (sys/sys/mount.h:477-484) to userspace, including two kernel-pointer fields:

struct vfsconf {
    struct vfsops *vfc_vfsops;            /* :478  -> .data (ops vector) */
    char  vfc_name[MFSNAMELEN];
    int   vfc_typenum;
    int   vfc_refcount;
    int   vfc_flags;
    STAILQ_ENTRY(vfsconf) vfc_next;       /* :483  -> .data (list link)  */
};

The sysctl node is registered with no privilege gate (sys/kern/vfs_subr.c:1850):

SYSCTL_NODE(_vfs, VFS_GENERIC, generic, CTLFLAG_RD, vfs_sysctl,
    "Generic filesystem");

CTLFLAG_RD means readable by any user, and sysctl_root() privilege-checks only writes, so the read path is ungated — confirmed by the PoC running as uid=1001(maxx) (not in wheel) and succeeding.

The legacy sysctl_ovfs_conf_iter() path (sys/kern/vfs_subr.c:1863) copies vfc_vfsops verbatim into struct ovfsconf (whose vfc_vfsops is a raw void *, sys/sys/mount.h:487) — same leak via the older mib.

Evidence — the leak is real

Running ./leak_vfsconf as the unprivileged maxx user leaked 11 filesystem entries. Each vfc_vfsops value matches an exact symbol in nm /boot/kernel/kernel:

Plus 10 vfc_next linked-list pointers (the 11th, tmpfs, is the list tail so its vfc_next is correctly 0x0). Kernel segment bounds from nm: btext=0xffffffff802aa4a0, etext=0xffffffff80c369d1 — every leaked address lands in the kernel .data segment immediately above etext, confirming they are genuine in-kernel addresses, not garbage.

The output is byte-identical across three consecutive runs (see run.log, run.2.log, run.3.log) — this is a deterministic leak of static addresses, not stack-residue noise, which makes it a particularly reliable KASLR-defeat: the relative offsets between the leaked symbols are constant and directly reveal the kernel's load base.

Impact

Information disclosure only (no memory contents beyond the pointer values themselves). Standalone impact is Low, but it is a prerequisite primitive for exploiting any future local kernel memory-corruption bug on this kernel: once the kernel text/data base is known, gadgets/RIP/jop-frames can be relocated precisely. Reachable by any unprivileged local user, default kernel, no config.

Exploit chain

None for this class (pure info-leak). The leaked addresses feed a second bug (gadget relocation for an arbitrary-write/UAF), they do not themselves corrupt memory. No further primitive is derivable from this node alone.

PoC changes

None to the source — the supplied leak_vfsconf.c compiled and ran correctly on the first attempt. Added the repro glue (build.sh, run.sh) and the full evidence logs (build.log, run.log, run.2.log, run.3.log, leak_sample.txt, env.txt, manifest.json, fix.diff).

How to reproduce

./build.sh        # as maxx: cc -o leak_vfsconf leak_vfsconf.c
./run.sh          # as maxx: dumps vfc_vfsops / vfc_next per fs type

On a fixed kernel the printed vfc_vfsops/vfc_next would be 0x0 and the PoC exits 2 (no kernel pointers observed).

References

• sys/kern/vfs_subr.c:1845 — VFS_CONF raw SYSCTL_OUT of whole struct vfsconf.
• sys/kern/vfs_subr.c:1850 — vfs.generic node CTLFLAG_RD, no privilege gate.
• sys/kern/vfs_subr.c:1863 — legacy sysctl_ovfs_conf_iter copies vfc_vfsops verbatim.
• sys/sys/mount.h:478 — struct vfsops *vfc_vfsops (kernel .data pointer).
• sys/sys/mount.h:483 — STAILQ_ENTRY(vfsconf) vfc_next (kernel .data list pointer).
• sys/sys/mount.h:487 — struct ovfsconf.vfc_vfsops (void *, legacy leak).
• CWE-200 Exposure of Sensitive Information to an Unauthorized Actor.