CVE-2026-93139 in Linux
Summary
by MITRE • 09/18/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/mes: Fix hung_queue_db_array loop limit for multi-XCC
The loop iterated only AMDGPU_MAX_MES_PIPES times, leaving entries uninitialized for multi-XCC GPUs. This causes null pointer dereferences when accessing arrays indexed by XCC ID >= 2. Extend the loop to cover all XCCs (AMDGPU_MAX_MES_PIPES * num_xcc), matching other per-XCC arrays.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability identified in the Linux kernel's AMD GPU driver, specifically within the Direct Rendering Manager subsystem for Advanced Micro Devices graphics processing units, involves a critical logic error in the initialization of queue database arrays associated with Message Engine Scheduler instances. This flaw manifests primarily on hardware configurations featuring multiple XCCs, which are distinct compute clusters or execution contexts within modern AMD GPUs such as those based on the RDNA architecture. The root cause lies in an insufficient loop limit during the setup phase where driver structures for managing these queues are populated. Instead of iterating across all available XCC units to initialize their respective data structures, the code incorrectly constrained the iteration count to a fixed maximum number of pipes defined by AMDGPU_MAX_MES_PIPES. This static bound fails to account for systems with more than one or two XCCs, resulting in uninitialized memory entries for any XCC ID greater than or equal to two.
From a technical perspective, this oversight leads directly to null pointer dereferences when the driver attempts to access array elements indexed by higher XCC IDs. Since the initialization loop does not cover these additional units, pointers within the data structures remain unset or contain garbage values rather than valid memory addresses allocated for queue management. When subsequent operations attempt to interact with these uninitialized entries, such as scheduling workloads or managing hardware queues, the kernel encounters invalid memory references. This typically results in immediate system instability, manifesting as a kernel panic or an automatic reboot of the host machine due to the severity of accessing null pointers within critical driver code paths that operate at ring buffer level and require strict memory safety guarantees.
The operational impact of this vulnerability is significant for users running multi-XCC AMD GPUs, which include many high-end desktop graphics cards and professional workstation accelerators. An attacker or even a benign user application triggering specific GPU workloads could exploit this condition to cause a denial of service by crashing the kernel. While direct remote code execution via this specific null pointer dereference is unlikely without additional adjacent vulnerabilities, the resulting system crash disrupts availability and can potentially lead to data loss if unsaved state exists in volatile memory at the time of the fault. The vulnerability aligns with CWE-476, which describes a NULL Pointer Dereference, indicating that the software performs an operation on a pointer variable when its value is such that it will result in a dereference of a null pointer.
Mitigation for this issue requires applying the upstream kernel patch that corrects the loop boundary condition to dynamically scale with the number of detected XCC units. The fix extends the iteration limit from AMDGPU_MAX_MES_PIPES to AMDGPU_MAX_MES_PIPES multiplied by num_xcc, ensuring that every hardware execution context receives properly initialized queue database arrays consistent with other per-XCC structures in the driver. System administrators should ensure their Linux kernels are updated to versions containing this fix, particularly if utilizing recent AMD GPU architectures known for multi-XCC designs. Regularly updating kernel packages and monitoring vendor security advisories remains the primary defense against such logic errors that compromise system stability through improper resource initialization.