CVE-2026-99006 in Linux
Summary
by MITRE • 10/23/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/i915/gem: Prevent overstepping exec array boundary
It is possible for eb_relocate_parse_slow() to call kvfree() on entries outside the original exec array during following scenario inside eb_relocate_parse_slow():
1) eb_copy_relocations() allocates as many as eb->buffer_count copies for exec entries; 2) eb_parse() appends up to two VMAs, right after incrementing eb->buffer_count; 3) cleanup under "out" label uses this incremented buffer_count to release relocation pointers from exec array via kvfree(), not from VMA array.
To amend this problem, ensure that relocation cleanup uses the original exec object count, excluding the VMAs appended by the command parser.
(cherry picked from commit 2a0158925fb943c7ba8f3216e2734952128defc9)
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/24/2026
The vulnerability identified in the Linux kernel's Intel graphics driver, specifically within the drm/i915/gem subsystem, represents a critical memory management flaw rooted in incorrect boundary handling during relocation entry processing. The core issue resides in the eb_relocate_parse_slow function, which is responsible for parsing and validating buffer relocations required by GPU command buffers. This routine interacts with two distinct data structures: the original exec array containing user-supplied buffer references and an internal VMA (Virtual Memory Area) array that may be dynamically extended during execution. The flaw arises from a failure to distinguish between these two sets of objects when performing cleanup operations, leading to out-of-bounds memory access scenarios that can compromise system stability and security.
The technical mechanism of the exploit involves a sequence of allocation, modification, and deallocation steps where state consistency is lost. Initially, eb_copy_relocations allocates copies for exec entries based on the initial buffer count provided by the user application. Subsequently, during the parsing phase via eb_parse(), the kernel may append up to two additional VMAs to handle complex rendering scenarios, incrementing the internal eb->buffer_count variable to reflect this new total size. However, when an error occurs or normal completion triggers cleanup under a specific label, the code incorrectly utilizes this incremented buffer count to determine how many pointers to free via kvfree(). Because the original exec array was sized only for the initial user-supplied entries, accessing indices beyond that limit results in reading and freeing memory outside the allocated boundary. This constitutes an out-of-bounds write or use-after-free condition depending on the specific execution path and memory state at the time of deallocation.
From a security perspective, this vulnerability aligns with CWE-125, Out-of-bounds Read, and potentially CWE-416, Use After Free, as the kernel attempts to release pointers that do not belong to the original allocation context. In the ATT&CK framework, such memory corruption issues in kernel drivers are often associated with techniques involving local privilege escalation or denial of service through system crashes. An attacker who can submit crafted GPU command buffers to the i915 driver could trigger this code path repeatedly or under specific timing conditions to corrupt kernel heap metadata. This corruption can lead to arbitrary code execution if the freed memory is reallocated and manipulated, or it may simply cause a kernel panic resulting in a denial of service against the entire system. The impact is severe because it affects the root level of the operating system through a graphics driver interface that is often accessible by unprivileged users.
Mitigation strategies for this vulnerability primarily involve applying the specific upstream Linux kernel patch that corrects the cleanup logic to use the original exec object count rather than the dynamically modified buffer count. System administrators should ensure their kernels are updated with versions containing commit 2a0158925fb943c7ba8f3216e2734952128defc9 or later backports of this fix. For environments where immediate patching is not feasible, restricting access to the DRM device nodes and enforcing strict user quotas on GPU command buffer submissions can reduce the attack surface. Additionally, enabling kernel hardening features such as KASAN (Kernel Address Sanitizer) in development builds helps detect these out-of-bounds accesses early during testing phases before deployment to production systems. Long-term remediation requires rigorous code review practices focused on state consistency between allocation and deallocation phases in complex driver subsystems like GEM.