CVE-2026-31656

What it actually does

This is a local Linux kernel vulnerability in the Intel i915 DRM graphics driver. A race condition exists between the i915 heartbeat worker and the engine parking path, where both can release the same engine->heartbeat.systole request. Because the pointer was read and cleared in separate non-atomic operations, two CPUs could observe the same non-NULL pointer and both call i915_request_put(), causing a reference count underflow and potential use-after-free. In practical terms, a local user able to exercise the i915 graphics driver may be able to trigger kernel memory corruption, leading to system crash, denial of service, or potentially local privilege escalation depending on kernel configuration, memory layout, and exploit reliability.

Why it matters to the business

Systems using affected Linux kernels with Intel i915 graphics support may be exposed to local attacks that can destabilize the host or, in a worst case, allow a lower-privileged user or compromised local process to gain elevated control. This is most relevant for Linux desktops, workstations, developer laptops, GPU-enabled systems, shared compute hosts, kiosk systems, and virtualized or containerized workloads that expose direct GPU access. The issue is not known to be exploited in the wild, is not in the CISA KEV catalog, has very low EPSS, and currently has no public exploit maturity, so remediation should be handled through normal kernel patch cycles unless the affected systems are multi-user or expose GPU access to untrusted workloads.

How an attack unfolds

An attacker first needs local code execution with sufficient ability to interact with the Intel i915 graphics stack, typically through normal user-space graphics APIs or workloads that submit requests to the GPU. The attacker repeatedly drives i915 request creation, completion, retirement, and engine idle transitions to increase the likelihood that the heartbeat worker and engine parking path run concurrently on different CPUs. If the race is won, both paths may release the same heartbeat request, causing a refcount underflow and use-after-free condition in kernel memory. A simple exploit attempt may only trigger a kernel warning, GPU hang, driver instability, or system crash. A more advanced exploit would attempt to shape kernel heap state around the freed request object and reclaim that memory with attacker-controlled data to influence subsequent kernel behavior, potentially escalating privileges. There is no indication from the provided intelligence that public exploit code or active exploitation currently exists.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the i915 heartbeat request race. The fix replaces the non-atomic read-and-clear sequence with an atomic xchg() operation so only one racing path can obtain and release the request pointer. No exact fixed package versions were provided, so remediation should be performed by installing the latest security-supported kernel from the operating system vendor or by ensuring the kernel contains the upstream commit referenced in the advisory: 13238dc0ee4f9ab8dafa2cca7295736191ae2f42. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads on systems with Intel i915 graphics, avoiding GPU device passthrough to untrusted containers or VMs, and disabling or avoiding use of the i915 driver on systems where Intel graphics is not required.

How to confirm the fix worked

Confirm exposure by checking whether the system uses an affected Linux kernel and whether the i915 module is loaded or available. Validate remediation by verifying that the running kernel package is updated to a vendor release containing the fix, or by confirming that the source/build includes the atomic xchg() change in the i915 heartbeat cleanup paths. Operationally, review kernel logs after patching for absence of refcount underflow warnings, i915 heartbeat-related warnings, GPU hangs, or call traces involving intel_engine_park_heartbeat(), i915_request_put(), and engine_retire. Because the vulnerability is a race condition, lack of a crash or warning does not prove safety; kernel version or source-level confirmation is the reliable validation method.

Typical attack path

1. Gain local code execution on a Linux system running an affected kernel with the Intel i915 DRM driver active.
2. Interact with the graphics subsystem to generate i915 GPU requests and heartbeat activity.
3. Create timing pressure by repeatedly causing request completion, retirement, engine idle, and engine parking events across CPUs.
4. Attempt to win the race between the heartbeat worker and intel_engine_park_heartbeat() so both paths release the same heartbeat request.
5. Trigger refcount underflow and possible use-after-free in the i915 kernel driver.
6. Use the resulting condition to crash the system, destabilize the graphics stack, or attempt kernel memory corruption for local privilege escalation.

How to detect it

Review kernel logs and persistent system journals for evidence of the i915 refcount underflow or related crash traces. Useful sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dumps, kdump/vmcore records, GPU hang reports, and endpoint telemetry that captures kernel oops or warning events. Look for warnings from refcount_warn_saturate, call traces containing intel_engine_park_heartbeat, i915_request_put, engine_retire, __engine_park, or i915-unordered workqueue activity. Also review authentication and process execution telemetry around the time of a crash or kernel warning to identify recently active local users, GPU-intensive workloads, container workloads with /dev/dri access, or suspicious repeated graphics-driver stress activity. There are no known attacker-specific network indicators for this local kernel race condition; detection is primarily host-based and symptom-driven.

• refcount_warn_saturate
• Workqueue: i915-unordered engine_retire [i915]
• intel_engine_park_heartbeat.part.0
• intel_engine_park_heartbeat+
• __engine_park+
• ____intel_wakeref_put_last
• __intel_wakeref_put_last
• intel_context_exit_engine
• intel_context_exit+
• i915_request_retire.part.0
• i915_request_retire+
• engine_retire+
• i915_request_put
• engine->heartbeat.systole
• /dev/dri/card0
• /dev/dri/renderD128
• GPU HANG: ecode
• i915: Resetting chip
• i915 0000:

What your security team should do

• Prioritize patching shared Linux systems, developer workstations, GPU-enabled compute nodes, and any hosts where untrusted users or workloads can access Intel i915 graphics devices.
• Inventory systems with the i915 module loaded using tools such as lsmod, modinfo, kernel package inventory, and endpoint telemetry.
• Update affected systems to the latest vendor-supported Linux kernel containing the i915 fix; reboot systems to ensure the patched kernel is actually running.
• If patching is delayed, restrict access to /dev/dri devices for untrusted users and workloads, and avoid passing Intel GPU devices into containers or virtual machines that are not fully trusted.
• Monitor kernel logs for refcount underflow, use-after-free symptoms, GPU hangs, and i915 call traces matching this issue.
• Treat any unexpected kernel crash or i915 refcount warning on multi-user systems as a potential security event requiring forensic review.
• Because EPSS is very low, KEV status is false, and exploit maturity is listed as none, track this through standard vulnerability management unless local multi-user exposure or untrusted GPU access increases risk.