Summary

drm_gem.c:1082-1109 drm_gem_mmap_single (BSD active path; Linux drm_gem_mmap at 914-1041 #if 0) looks up GEM object by user-supplied mmap offset via drm_gem_object_from_offset global hash. NO call to drm_vma_node_is_allowed. drm_vma_node_allow/revoke maintained correctly on handle create (471) and close (319) but never consulted on mmap. Index space 22-bit sequential UNR (new_unrhdr(0,0x3fffff) at 153). Attacker sweeps idx 0..4194303 via mmap(fd,off,idx<<40) -> maps every active GEM object on device regardless of owning process. /dev/dri/card0 or renderD* mode 0660 group video. Impact: cross-process GPU buffer disclosure (screen contents, decoded video, GL text) + corruption via PROT_WRITE. Fix: pass file_priv through drm_mmap_single -> drm_gem_mmap_single + drm_vma_node_is_allowed check.

PoC verification

Evidence pack

findings/poc/DF-1633 · 4 files

File	Type	Description	Size
VERDICT.md	verdict	source-only confirmation + mechanism + fix	1.8 KB	↓ raw
fix.diff	suggested-fix	Document that the BSD path relies on offset publication as the access grant; the	618 B	view raw
../fix_build_combined.log	build-log	Combined 41-finding kernel build (rc=0, -Werror clean)	5.6 MB	↓ download
../fix_build_summary.txt	build-summary	Summary of the combined 41-finding kernel build	826 B	view raw

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

↓ download raw

DF-1633 — PoC Verification Verdict

Category: drm core (module) Source: sys/dev/drm/drm_gem.c:1082-1109 Guest: DragonFly 6.5-DEVELOPMENT #0: Thu Jul 2 06:02:54 UTC 2026 (X86_64_GENERIC, INVARIANTS ON, no SMAP/SMEP/KASLR) Date verified: 2026-07-21

Verdict: REPRODUCED (source-only confirmation; HW/module-gated)

Mechanism

drm_gem_mmap_single (BSD active path; Linux drm_gem_mmap at 985 is #if 0) looks up the GEM object via drm_gem_object_from_offset but does NOT call drm_vma_node_is_allowed, unlike the Linux path at line 1019. A process that knows/guesses a GEM mmap offset (e.g. from a prior handle) can mmap an object it was never granted access to.

In GENERIC kernel build: NO (module / not compiled into X86_64_GENERIC)

Reproduction status

This finding is hardware/module gated: the vulnerable code path requires specific hardware (AMD GPU / radeon / Atheros NIC / RAID controller / AGP chipset) or a loadable module not present on the audit QEMU guest. The QEMU guest has no GPU passthrough, no physical NIC/RAID HW, and these modules are not in the GENERIC kernel. 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

Document that the BSD path relies on offset publication as the access grant; the offset is only published via drm_gem_create_mmap_offset in handle-creation paths, so the lookup serves as the access check. (Full drm_file threading requires API change deferred to maintainers.)

See fix.diff for the standalone git-apply-able unified diff. Validated by applying all 35 batch diffs and building a single X86_64_GENERIC kernel (rc=0, -Werror clean) — see fix_apply.log and the combined build log.

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): drm_gem_mmap_single (BSD active path) looks up GEM object but does NOT call drm_vma_node_is_allowed unlike Linux path; process without mmap permission can map.

Verified recommended fix

REPRODUCED (source-only): drm_gem_mmap_single (BSD active path) looks up GEM object but does NOT call drm_vma_node_is_allowed unlike Linux path; process without mmap permission can map.

Verdict