CVE-2026-80576: drm/amdgpu: reject oversized IBs with per-ring packet limits
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: reject oversized IBs with per-ring packet limits
On GFX rings, amdgpucsp2ib() passed user-supplied ibbytes through to ib->lengthdw without a limit, while ringemitib() 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)
Affected Software
Event History
Frequently Asked Questions
Who is exposed to this issue?
Systems using the Linux kernel amdgpu driver are exposed when untrusted users can submit GPU command streams that reach amdgpu_cs_p2_ib(). The issue concerns user-supplied instruction-buffer sizes on AMDGPU command-submission rings.
What does an attacker need to do to trigger the vulnerability?
An attacker needs to submit an instruction buffer whose byte size exceeds the packet-length field supported by the target ring. The oversized size is converted to a dword length and encoded into ring packet fields, potentially corrupting adjacent control bits.
Which ring types have an explicit documented limit?
GFX, compute, SDMA, and VPE rings use a documented 20-bit instruction-buffer packet limit. Other ring types use an MM fallback limit.
What mitigation is available if the update cannot be applied immediately?
The provided data does not identify a configuration workaround. Reducing access to AMDGPU command submission by untrusted users may reduce exposure, but this is not specified as a vendor-provided mitigation.