Linux kernel amdgpu GEM/VM/command-submission ioctl surface (drm/amdgpu): A race condition or locking defect

Impact

A race condition or locking defect in the amdgpu GEM/VM/command-submission ioctl surface. Concurrent paths touch shared state without the right serialisation, so the outcome depends on timing an attacker can influence by hammering the interface from several threads. The visible symptom is a deadlock or hang that wedges the GPU and any job on it; the worse outcome, when the race lands on an object lifetime, is memory corruption. Upstream fix: drm/amdgpu: fix amdgpu_irq_put call trace in gmc_v10_0_hw_fini

Who can reach it

Local. Reachable by any process with /dev/dri/renderD* open - the render node is handed to tenant containers by every GPU device plugin, so this is unprivileged-tenant reachable. 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