GPU VulnDB

Database/NVIDIA / GPU stack

Linux kernel amdgpu: user-supplied indirect buffer size is unbounded, corrupting ring packet fields

UnscoredCVE-2026-80576NVIDIA / GPU stackcurated

Impact

amdgpu_cs_p2_ib() passed the user-supplied ib_bytes straight into ib->length_dw with no upper limit, while ring_emit_ib() packs that length into packet header fields. An oversized value overflows the field and corrupts adjacent control bits in the submitted packet, which the commit describes as destabilizing command submission. On a shared AMD GPU node this is reachable by whoever holds the render node, so one tenant's malformed submission can wedge the ring for everything else on the device; recovering a hung GFX/compute ring generally means a GPU reset and, in practice, evicting the workloads on that card. The record does not claim memory disclosure or privilege escalation, only command-submission corruption.

Who can reach it

Local user able to open an amdgpu render node and submit command buffers - on a GPU cluster, any tenant with a pod that has /dev/dri/renderD* mapped in. No elevated privileges beyond device access are needed.

What to do

Update to a stable kernel carrying the per-ring IB packet size limit and reboot each AMD GPU node; the fix is in the kernel driver's submission path, so a module reload is not viable while jobs hold the device. Drain the node first. No advisory version numbers are given in the record - only the stable branch commits and the upstream cherry-pick.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-80576https://git.kernel.org/stable/c/07fe270ec07c138a70afe7a81e115a85c35c545chttps://git.kernel.org/stable/c/1474f3970d1afd303e12ff14d06808eabb371576https://git.kernel.org/stable/c/6e164ba1057175fb8a370d8e05cbff5c57eac0c8

Related entries

All NVIDIA / GPU stack entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.