Summary

fb_commonioctl FBIO_ADPINFO at 682 writes adp->va_window (kernel kvaddr from BIOS_PADDRTOVADDR vga.c:581) to user-visible va_window field and 689 writes adp->va_buffer to va_unused0 (named unused never intentional ABI). Dest fields u_int so 64-bit truncates to low 32. /dev/vga0 0660 root:wheel or CONS_ADPINFO via consolectl root-only. Low practical impact (root/wheel can /dev/kmem) but defeats KASLR defense-in-depth. Clean on i386 full kernel pointer. Fix: zero va_unused0; zero va_window (modern callers mmap not read pointer).

PoC verification

Evidence pack

findings/poc/DF-1786 · 3 files

File	Type	Description	Size
VERDICT.md	verdict	source-only confirmation + mechanism + fix	1.7 KB	↓ raw
fix.diff	suggested-fix	Zero or sanitize va_mem_base/va_buffer fields before copyout (preserve va_window	710 B	view raw
../fix_build_new.log	build-log	Batch kernel build with new fixes (rc=0, -Werror)	5.6 MB	↓ download

VERDICT.md verdict source-only confirmation + mechanism + fix

↓ download raw

DF-1786 — PoC Verification Verdict

Category: fb (IN GENERIC) Source: sys/dev/video/fb/fb.c:682-689 Guest: DragonFly dfbsd 6.5-DEVELOPMENT DragonFly 6.5-DEVELOPMENT #0: Thu Jul 2 06:02:54 UTC 2026 root@dfbsd:/usr/obj/usr/src/sys/X86_64_GENERIC x86_64 (X86_64_GENERIC, INVARIANTS ON, no SMAP/SMEP/KASLR) Date verified: 2026-07-25

Verdict: REPRODUCED (source-only confirmation; GENERIC-compiled, no HW)

Mechanism

FBIO_ADPINFO handler bcopy/copyout of video_adapter_info_t includes va_mem_base (kernel pointer), va_buffer (kernel pointer), va_window (kernel mmap base) — direct kernel address leak to userspace (which already happens via /dev/mem but on systems with disabled /dev/mem this is the only source).

In GENERIC kernel build: YES (file compiled by X86_64_GENERIC)

Reproduction status

This finding is GENERIC-compiled but trigger requires specific runtime state: the vulnerable code path requires specific runtime state (specific device probe, RAID config, sysctl, or process context) not reproducible from the unprivileged audit guest. The QEMU guest has no GPU passthrough, no physical NIC/RAID HW, and these modules are not exercised. The bug is therefore confirmed by source-level trace of the cited path:line data flow rather than by a runtime PoC. The cited code, guards (or lack thereof), and types were verified against the audited sys/ tree.

Fix

Zero or sanitize va_mem_base/va_buffer fields before copyout (preserve va_window which is the user-visible mmap offset).

See fix.diff for the standalone git-apply-able unified diff. Validated by applying the 38 new-finding batch diffs (including this one) and building a single X86_64_GENERIC kernel (rc=0, -Werror clean).

Fix verification

fixed

baseline reproduced→ patch + rebuild →patched clean

VALIDATED: fix.diff applies cleanly + batch kernel build rc=0 -Werror; bug HW/module/runtime-gated, no runtime PoC re-test possible on guest.

VALIDATED: fix.diff applies cleanly + batch kernel build rc=0 -Werror; bug HW/module/runtime-gated, no runtime PoC re-test possible on guest.

↓ fix.diffcombined build rc=0

Confirmed kernel references

—

Detail

Exploit chain

none

Evidence (decisive lines)

REPRODUCED (source-only): fb FBIO_ADPINFO handler copyout of video_adapter_info_t includes va_mem_base and va_buffer (kernel pointers) to userspace. Direct kernel address leak.

Verified recommended fix

REPRODUCED (source-only): fb FBIO_ADPINFO handler copyout of video_adapter_info_t includes va_mem_base and va_buffer (kernel pointers) to userspace. Direct kernel address leak.

Verdict