GPU VulnDB

Database/NVIDIA / GPU stack

amdgpu: rings outside a partition index the isolation array out of bounds on SDMA submit

CVSS 7.8CVE-2026-89814NVIDIA / GPU stackcurated

Impact

adev->isolation[] has one entry per XCP partition, but a ring that belongs to no partition keeps AMDGPU_XCP_NO_PARTITION (~0) as its index. SDMA submissions read the array with that value on both the isolation-enforcement and VM-flush paths, an out-of-bounds access that trips UBSAN. The affected code is the compute-partitioning isolation machinery on MI-class accelerators - exactly the mechanism a GPU cloud relies on to keep two tenants sharing one physical GPU apart - and it is hit on a routine submit path, not an exotic one. The record establishes an out-of-bounds array index on every SDMA submit from an unpartitioned ring; it does not establish that isolation between partitions is defeated, so treat this as kernel memory-safety on the partitioning path rather than a proven tenant-escape.

Who can reach it

Local. Any tenant whose container holds an amdgpu render node on a partition-capable GPU and submits SDMA work; reached through normal submission, no crafted command buffer described.

What to do

Apply the stable-kernel update that falls back to isolation slot 0 for rings with no partition and defers taking the address until after the ring-type check. In-tree amdgpu change, so it arrives with the kernel: drain and reboot each affected node, or rebuild and reload the packaged AMD module with GPUs idle. Nodes not using XCP compute partitioning still run the same code path and should be patched on the same cycle.

References

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.