Linux kernel amdgpu RAS / GPU reset and recovery path (drm/amdgpu): MULTI-TENANT ISOLATION: A use-after-free

Impact

MULTI-TENANT ISOLATION: A use-after-free in the amdgpu RAS / GPU reset and recovery path. Freed kernel memory is reachable again through a later operation, so an attacker who can win the timing and reoccupy the freed slab object gets a write (or a controlled read) into live kernel memory. In practice this is a local-privilege-escalation primitive: from inside a GPU container it is a route to host kernel code execution, and from there to every other tenant's GPU memory and data on the node. Unexploited, it is a kernel panic that takes the whole node down mid-job. Upstream fix: drm/amdgpu: Fix context pstate override handling

Who can reach it

Local. Reachable by a local user who can trigger or observe a GPU reset, plus anything that can induce ECC/RAS events; some paths are only reachable by the node's own error handling. 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.

References