CVE-2026-80576 in Linux
Summary
by MITRE • 08/26/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: reject oversized IBs with per-ring packet limits
On GFX rings, amdgpu_cs_p2_ib() passed user-supplied ib_bytes through to ib->length_dw without a limit, while ring_emit_ib() encodes length into packet fields. Oversized values can corrupt adjacent control bits and destabilize command submission.
Add a per-ring IB packet size limit helper and reject command submissions exceeding the corresponding dword limit before IB allocation. Use the documented 20-bit limit for GFX/compute/SDMA/VPE, and apply the MM fallback limit for other ring types.
(cherry picked from commit 7f48fa2cf62e3fa6c9c3870aa74988f773247e52)
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/26/2026
The Linux kernel driver for AMD graphics processing units, specifically the amdgpu subsystem, contained a critical input validation flaw within its command submission pipeline. The vulnerability originated in the function amdgpu_cs_p2_ib(), which is responsible for handling indirect buffer submissions from user-space applications. In this routine, the size of the indirect buffer provided by the user was passed directly into the internal ib->length_dw structure without any upper bound checking or validation against hardware-specific constraints. This lack of boundary enforcement allowed malicious or buggy userspace processes to specify an arbitrarily large buffer length that exceeded the physical and logical limits imposed by the GPU architecture.
The technical severity of this flaw is amplified by how the kernel subsequently processed these unchecked values. The function ring_emit_ib() takes the ib->length_dw value and encodes it into specific packet fields within the command stream sent to the hardware. These packet fields have fixed bit-widths, typically limited to 20 bits for GFX, compute, SDMA, and VPE rings as per AMD documentation. When a user-supplied length exceeds this limit, the encoding process causes integer overflow or truncation issues that corrupt adjacent control bits within the command packet. This corruption does not merely result in an invalid buffer size; it alters critical metadata associated with the command submission sequence, leading to unpredictable behavior in the GPU command processor.
The operational impact of this vulnerability is significant, primarily manifesting as instability and potential denial of service conditions for the graphics subsystem. By corrupting adjacent control bits, oversized indirect buffers can destabilize the entire command submission pipeline. This may lead to GPU hangs, system crashes, or undefined behavior where subsequent commands are misinterpreted by the hardware. While direct code execution is not explicitly detailed in the initial report, the corruption of kernel-managed data structures and hardware registers via user-supplied input represents a serious breach of isolation boundaries between userspace applications and privileged kernel components. Such instability can disrupt all graphical operations on the system, affecting both local console sessions and remote display services like X11 or Wayland compositors that rely on stable GPU operation.
To mitigate this vulnerability, the fix introduces a per-ring indirect buffer packet size limit helper function within the amdgpu driver codebase. This mechanism enforces strict validation before any memory allocation occurs for the indirect buffer. Specifically, it rejects command submissions where the requested length exceeds the documented 20-bit dword limit applicable to GFX, compute, SDMA, and VPE rings. For other ring types that do not adhere to this specific standard, a fallback MM (memory management) limit is applied to ensure no submission can exceed hardware capabilities regardless of the ring type. This preventive measure ensures that only valid, size-constrained requests are processed by the kernel driver, thereby preserving the integrity of command packet encoding and preventing control bit corruption.
From a security classification perspective, this vulnerability aligns with CWE-190 Integer Overflow or Wraparound, as the unchecked input leads to improper handling when values exceed expected bounds during processing. It also relates to CWE-20 Improper Input Validation, since the driver failed to verify that user-supplied data conformed to architectural constraints before use. In terms of attack vectors and tactics, this flaw could be exploited by a local attacker with access to GPU devices or rendering contexts to cause denial of service through resource exhaustion or system instability. This maps to MITRE ATT&CK technique T1499 Endpoint Denial of Service, where an adversary leverages software vulnerabilities to disrupt the availability of computing resources. The remediation strategy emphasizes defense-in-depth by validating input at the earliest possible stage in the processing pipeline, preventing malformed data from propagating into critical subsystems that interact directly with hardware registers.