• File: sys/dev/drm/i915/i915_gem_evict.c
• Lines: 156, 200–202
• Severity: Low
• CVSS 3.1: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:L
• CWE: CWE-532 Insertion of Sensitive Information into Log File
• Confidence: certain
• Status: new

Summary

Two unconditional kprintf() calls in i915_gem_evict_something() execute on every GTT eviction, printing internal GPU virtual address ranges and GPU idle state to the kernel log and console.

DragonFlyBSD does not restrict dmesg access for unprivileged users, so this leaks the VM's GTT address-space layout.

Worse, because eviction is triggerable at high rates by any user with /dev/dri render access, an attacker can flood the kernel log ring buffer and serial/VGA console with synchronous output, causing performance degradation and displacing forensic log entries.

Root cause

At i915_gem_evict.c:156, kprintf("i915_gem_evict_something: %016llx-%016llx\n", start, end) prints the GTT eviction range on every call.

At i915_gem_evict.c:200-202, kprintf("i915_gem_evict_something: Nothing found %d,%d\n", ggtt_is_idle(dev_priv), intel_has_pending_fb_unpin(dev_priv)) prints internal driver state when eviction initially fails.

Neither call is guarded by a debug flag, DRM_DEBUG macro, or rate limiter. These appear to be debug instrumentation left in the DragonFly port (similar stray kprintf calls exist throughout i915_gem.c — 26 occurrences).

The function is called from i915_gem_gtt_insert (gtt.c:4124) on every VMA bind that requires eviction, which is in turn called from the execbuf hot path reachable via DRM_IOCTL_I915_GEM_EXECBUFFER2 from any unprivileged render client.

Threat model

Attacker position: any local user with access to /dev/dri/cardN or /dev/dri/renderDN (typically the video group or world-readable on default DragonFlyBSD desktop/server setups).

Trigger: 1. fill the GGTT or PPGTT with many small pinned VMAs, 2. submit execbufs that bind new objects requiring eviction.

Each eviction emits 1–2 kprintf lines. At thousands of execbufs/second, this saturates:

• (a) the dmesg ring buffer — displacing security-relevant log entries (CWE-532 info leak + forensic evidence loss);
• (b) on serial console systems (common in data centers), the synchronous char-by-char console output at 115200 baud (~87 µs/char, ~5 ms per 60-char line) causes severe performance degradation of all kernel operations contending for console output.

The leaked %016llx values are GPU virtual addresses (not host pointers), limiting the info-leak severity to GTT address-space layout disclosure (useful for GPU-side ASLR defeat or cross-VM side-channel in SR-IOV/GVT-d setups).

Proof of concept

/* evict_spam.c -- build: cc -o evict_spam evict_spam.c -ldrm
 * Run as any user with /dev/dri/renderD128 access.
 *
 * 1. Open /dev/dri/renderD128 via drmOpen.
 * 2. Create a GPU context via DRM_IOCTL_I915_GEM_CONTEXT_CREATE.
 * 3. Create many (e.g. 4096) small GEM objects (4KB each) via
 *    DRM_IOCTL_I915_GEM_CREATE.
 * 4. Submit a batch that binds all of them into the PPGTT via
 *    DRM_IOCTL_I915_GEM_EXECBUFFER2 with relocs, filling the address space.
 * 5. In a tight loop, create a new GEM object and submit execbuf with
 *    PIN_HIGH to force it into a high address -- triggering eviction of
 *    existing VMAs to make room. Each iteration causes
 *    i915_gem_evict_something to fire and emit the kprintf.
 */

Run dmesg -w in another terminal to observe the flood. On a serial console, observe interactive latency spike. Use vmstat 1 to show CPU time in kernel (printf subsystem).

Success criterion: dmesg ring buffer overflows with i915_gem_evict_something: lines within seconds; console becomes unresponsive on serial; kern.msgbuf_fill sysctl (if available) shows ring buffer at 100% capacity.

No kernel panic — this is a degradation DoS, not a crash.

Recommended fix

Remove the two kprintf calls. They are debug instrumentation not present in upstream Linux i915_gem_evict.c and serve no production purpose. If diagnostic output is desired, gate behind DRM_DEBUG_DRIVER() or i915_modparams debug flags.

--- a/sys/dev/drm/i915/i915_gem_evict.c
+++ b/sys/dev/drm/i915/i915_gem_evict.c
@@ -153,8 +153,6 @@ int
     * object on the TAIL.
     */

-   kprintf("i915_gem_evict_something: %016llx-%016llx\n", start, end);
-
    mode = DRM_MM_INSERT_BEST;
    if (flags & PIN_HIGH)
        mode = DRM_MM_INSERT_HIGH;
@@ -197,8 +195,6 @@ int
    if (!i915_is_ggtt(vm) || flags & PIN_NONBLOCK)
        return -ENOSPC;

-   kprintf("i915_gem_evict_something: Nothing found %d,%d\n",
-       ggtt_is_idle(dev_priv),
-       intel_has_pending_fb_unpin(dev_priv));
-
    /*
     * Not everything in the GGTT is tracked via VMA using
     * i915_vma_move_to_active(), otherwise we could evict as required

References

• sys/dev/drm/i915/i915_gem_evict.c:156 — kprintf of GTT range
• sys/dev/drm/i915/i915_gem_evict.c:200-202 — kprintf of driver state
• sys/dev/drm/i915/i915_gem_gtt.c:4124 — caller i915_gem_gtt_insert
• sys/dev/drm/i915/i915_gem_execbuffer.c:715 — execbuf hot path reaching eviction