GPU VulnDB

Database/NVIDIA / GPU stack

AMD Instinct GPUs: VCN-JPEG register space is not isolated between guest VMs or processes

CVSS 8.8CVE-2024-36323NVIDIA / GPU stackcurated

Impact

The JPEG cores inside the VCN block expose their hardware register space without proper per-VM/per-process isolation, so a malicious guest VM or local process can reach the registers belonging to a JPEG core assigned to a different VM or process. AMD rates the consequence as arbitrary read/write access to the victim's data, which on a shared Instinct node means a tenant boundary crossing inside a single GPU - exactly the boundary a multi-tenant GPU cloud sells. It affects MI300X, MI300A, MI325X and MI308X, the parts used for datacenter training and inference, so any node partitioned between tenants or between untrusted workloads is in scope. Confidentiality and integrity of co-resident tenant data are both implicated; the record does not describe a remote path.

Who can reach it

Local. A workload inside a guest VM with a virtualized Instinct GPU assigned to it, or a local process holding a GPU device node on a bare-metal node shared with other processes. Low privilege is sufficient (CVSS PR:L); no network access is needed.

What to do

Apply the GPU driver and firmware updates AMD lists in bulletin AMD-SB-6027 for the affected Instinct parts; the record does not state a fixed version, so take the version from the bulletin rather than assuming. In practice the GPU driver or VBIOS cannot be replaced under live tenants: drain the node's workloads and reboot it, and schedule per-node windows across the fleet. Until the node is patched, the only mitigation is to stop sharing a single GPU between tenants or trust domains that must not read each other's data.

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.