CVE-2026-63884

What it actually does

This is a Linux kernel use-after-free flaw in the Intel i915 Direct Rendering Manager graphics driver, specifically in the Translation Table Maps object purge path. Under certain GPU memory pressure, eviction, validation, or object placement changes can replace the backing TTM page-vector container while later code continues to use a stale pointer. A local user who can exercise the i915 graphics ioctl paths may be able to trigger a kernel crash and, depending on allocator state and exploit reliability, potentially corrupt kernel memory to gain elevated privileges. The CVSS vector indicates local access with low complexity and low privileges required, no user interaction, and high confidentiality, integrity, and availability impact.

Why it matters to the business

Systems using affected Linux kernels with Intel i915 graphics enabled may be exposed to local denial of service or local privilege escalation. On workstations, graphics hosts, shared Linux desktops, GPU-enabled build systems, kiosks, and multi-user servers with local shell or containerized access to GPU devices, exploitation could let a low-privileged user crash the host or potentially take full control of it. The vulnerability is not currently listed in CISA KEV, has low EPSS, and has no reported exploit maturity in the supplied data, but kernel local privilege escalation issues should still be prioritized where untrusted users or workloads can access /dev/dri devices.

How an attack unfolds

An attacker first needs local code execution as an unprivileged user on a Linux system using the vulnerable i915 driver, typically with access to Direct Rendering Infrastructure device nodes such as /dev/dri/card* or /dev/dri/renderD*. The attacker then drives i915 GEM/TTM operations through graphics ioctls, creating and manipulating GPU buffer objects so that memory pressure, eviction, movement, validation, or purge behavior is reached. In the vulnerable path, ttm_bo_validate() can change the buffer object's TTM backing object, while subsequent i915 purge logic may still treat an earlier pointer as valid and dereference freed or replaced memory. A simple exploit may only produce a kernel oops or panic, causing denial of service. A more advanced exploit would attempt to shape kernel heap allocations around the freed object so the stale pointer references attacker-influenced data, potentially turning the use-after-free into kernel memory corruption and privilege escalation.

How to fix it

Apply a Linux kernel update from the relevant distribution, vendor, or upstream stable kernel branch that includes the i915 TTM object purge fix for this vulnerability. No exact fixed package versions were provided in the input, so administrators should rely on their operating system vendor advisories and kernel changelogs for the corrected build. Reboot systems after installing the fixed kernel so the patched i915 module is loaded. Where immediate patching is not possible, reduce exposure by restricting untrusted local users and containers from accessing /dev/dri devices, removing unnecessary membership in video/render groups, disabling GPU passthrough to untrusted workloads, and considering temporary disablement or blacklisting of the i915 module only where operationally acceptable. Kernel hardening features, lockdown modes, module signing, and rapid crash monitoring can reduce risk but should not be treated as complete mitigations.

How to confirm the fix worked

Confirm the running kernel version is the vendor-fixed build, not just that the package is installed. On Linux systems, compare `uname -r` and distribution package metadata against the vendor advisory for this issue, then reboot if the running kernel predates the fixed package. Verify whether i915 is loaded with `lsmod | grep '^i915'` and whether GPU device nodes are exposed with `ls -l /dev/dri`. Review kernel logs after patching to confirm there are no recurring i915 TTM purge crashes, general protection faults, or call traces involving `i915_ttm_purge`, `i915_ttm_move`, `ttm_bo_validate`, or `i915_gem_execbuffer2_ioctl`. For mitigation validation, ensure untrusted accounts or containers cannot open `/dev/dri/card*` or `/dev/dri/renderD*` unless required.

Typical attack path

1. Obtain local low-privileged execution on a Linux host using the Intel i915 graphics driver.
2. Confirm access to GPU/DRM device nodes such as /dev/dri/card0 or /dev/dri/renderD128.
3. Use DRM/i915 GEM ioctl calls to allocate, bind, execute against, and evict GPU buffer objects.
4. Create memory pressure or object state transitions that force TTM buffer-object validation, movement, eviction, and purge handling.
5. Trigger the stale pointer dereference in the i915 TTM purge path after the backing TTM object has been replaced.
6. Cause a kernel oops/panic for denial of service or attempt heap grooming to convert the use-after-free into privilege escalation.

How to detect it

Detection should focus on host telemetry because this is a local kernel-driver issue rather than a network-exposed vulnerability. Review `dmesg`, journald, syslog, kdump, crash dumps, and EDR process telemetry for kernel oops or panic messages involving the i915 and TTM modules. Key artifacts include general protection faults in `i915_ttm_purge`, call traces through `i915_ttm_move`, `ttm_bo_evict`, `ttm_bo_validate`, `__i915_ttm_get_pages`, `i915_gem_do_execbuffer`, or `i915_gem_execbuffer2_ioctl`, especially when associated with untrusted user sessions or unusual GPU workload processes. Look for repeated GPU/DRM crashes, unexpected host reboots, or local processes rapidly opening `/dev/dri` devices and issuing high volumes of DRM ioctls. If crash dumps are available, examine whether the faulting pointer resembles freed slab poison patterns, such as repeated byte values, and correlate the timestamp with shell history, auditd exec events, container starts, or processes holding `/dev/dri/card*` or `/dev/dri/renderD*`. Absence of these artifacts does not prove non-exploitation because a successful privilege-escalation attempt may not leave a clean kernel oops.

• Oops: general protection fault, probably for non-canonical address
• RIP: 0010:i915_ttm_purge
• i915_ttm_purge+0x84/0x100 [i915]
• i915_ttm_move+0x2b9/0x420 [i915]
• ttm_bo_handle_move_mem
• ttm_bo_evict
• ttm_lru_walk_for_evict
• ttm_bo_alloc_resource
• ttm_bo_validate
• __i915_ttm_get_pages
• i915_ttm_get_pages
• i915_gem_do_execbuffer
• i915_gem_execbuffer2_ioctl
• /dev/dri/card
• /dev/dri/renderD
• Comm: Xorg
• RAX: a56b6b6b6b6b6b6b

What your security team should do

• Inventory Linux systems with Intel i915 graphics enabled, prioritizing multi-user hosts, shared workstations, VDI fleets, GPU-enabled CI/build infrastructure, and container platforms exposing /dev/dri devices.
• Patch affected systems with the vendor-fixed kernel as soon as practical and ensure they are rebooted into the fixed kernel.
• Restrict access to /dev/dri/card* and /dev/dri/renderD* for untrusted users and workloads until patching is complete.
• Review group membership for video and render groups and remove unnecessary users, services, and containers.
• Monitor kernel logs for i915/TTM crash signatures that could indicate attempted exploitation or accidental triggering under load.
• If crashes matching this issue are observed, preserve kernel logs, audit local users with GPU access, and investigate recent processes using DRM/i915 ioctls.
• Track vendor advisories for exact fixed kernel versions because no fixed versions were supplied in the input.