GPU VulnDB

Database/NVIDIA / GPU stack

Linux kernel amdgpu user-mode queues (doorbell submission path) (drm/amdgpu): MULTI-TENANT ISOLATION: Missing

CVE-2026-43400NVIDIA / GPU stackcurated

Impact

MULTI-TENANT ISOLATION: Missing or insufficient validation of user-supplied parameters in the amdgpu user-mode queues (doorbell submission path). A value that crosses the ioctl boundary - a size, a count, an offset, a buffer-object mapping range - is trusted rather than checked, so a tenant can drive the driver outside the range its authors assumed. Where the unchecked value indexes or sizes a kernel allocation this is a memory-corruption primitive and therefore a host-compromise route out of a GPU container; where it only reaches a sanity check further down it costs the node a crash. Upstream fix: drm/amdgpu: add upper bound check on user inputs in signal ioctl

Who can reach it

Local. Reachable by any process with a render node open that can create user-mode queues - the normal ROCm submission path, reachable from an unprivileged container. Not reachable over the network and not reachable from a container that has no GPU device node mapped in.

What to do

Kernel-side fix: this lands in mainline Linux and flows into distro kernels (RHEL/Rocky, Ubuntu HWE, SLES) and into AMD's out-of-tree DKMS amdgpu package shipped with ROCm. Patch the kernel or the DKMS module, then **reload the amdgpu module or reboot the node** - you cannot fix a running driver in place. Reloading amdgpu requires no process holding /dev/kfd or a render node, so in practice this is a cordon + drain + reboot per node. Plan it as a rolling maintenance across the fleet; there is no VBIOS flash, no SBIOS/AGESA step and no firmware update involved. Nodes running the ROCm DKMS stack often lag mainline by a release or two, so confirm the fix is actually present in the AMD driver version you deploy rather than assuming a new distro kernel covers it. Until the reboot window, the only real mitigation is to stop handing the render node to untrusted workloads - the device plugin has to be mapping /dev/dri/renderD* and /dev/kfd into the container for a tenant to reach this at all.

References

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.