Description

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)

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-08-26T15:17:13.653Z",
  "pubdate": "2026-08-26T15:17:13.653Z",
  "executiveSummary": "A critical vulnerability exists in the Linux kernel's amdgpu driver, specifically involving the command submission (CS) interface. The issue stems from the insufficient validation of user-supplied Indirect Buffer (IB) lengths during command submission processing. By providing an oversized IB length, a local attacker can trigger an integer overflow or corruption within the command stream's packet headers, potentially leading to command stream manipulation or system instability.\nThis vulnerability affects the drm/amdgpu driver. The impact involves potential privilege escalation or denial of service, as an attacker can induce memory corruption by coercing the driver into misinterpreting packet control bits. Exploitation requires local access to the system with the capability to submit GPU commands (typically via /dev/dri/renderD* nodes). The risk is high due to the potential for kernel-mode memory corruption within the GPU command stream processor.",
  "technicalDetails": "The vulnerability resides within the amdgpu_cs_p2_ib() function, which is responsible for parsing user-supplied command submissions. During the command submission workflow, the driver consumes an ib_bytes value directly from user space and assigns it to ib->length_dw without applying adequate bounds checking. The core issue is that the underlying hardware (GFX, compute, SDMA, and VPE rings) uses a fixed-width field—specifically a 20-bit field—to encode the length of Indirect Buffers within command packets.\nWhen a user provides an IB length that exceeds the capacity of the hardware-encoded 20-bit field, the excess bits overflow into adjacent control fields of the command packet. In the hardware command processor, these corrupted control bits are treated as valid instructions or configuration directives. This discrepancy between the software-calculated length and the hardware's expected packet format enables an attacker to inject arbitrary command stream data or manipulate the GPU's memory access path.\nThe attack flow follows these steps: 1) The attacker constructs a malicious command submission containing an oversized IB length value. 2) The user-space application invokes the DRM_IOCTL_AMDGPU_CS ioctl. 3) The kernel driver amdgpu_cs_p2_ib() fails to validate the user-supplied length against the maximum permissible size for the specific ring type. 4) The driver proceeds to ring_emit_ib(), where the oversized length is encoded into the hardware packet. 5) The command processor reads the malformed packet, causing it to misinterpret command boundaries or write data to unintended memory locations due to the overflow of control bits.\nThis behavior results in a deviation from the expected GPU state, allowing for potential memory corruption or kernel-mode instability. By overwriting adjacent packet fields, an attacker can influence the execution flow of the GPU command processor, which may be leveraged to gain unauthorized access to system resources or perform a denial of service attack against the kernel driver."
}