Linux kernel amdgpu power management (SMU/powerplay) (drm/amd/pm): A correctness defect in the amdgpu power management

CVSS 5.5CVE-2026-23213NVIDIA / GPU stackcurated

Impact

A correctness defect in the amdgpu power management (SMU/powerplay) reachable through the driver's user-facing interface. The practical effect is an unstable or crashing GPU driver on a shared node. Upstream fix: drm/amd/pm: Disable MMIO access during SMU Mode 1 reset

Who can reach it

Local. Reachable by a local user with root or with write access to the amdgpu sysfs/debugfs power interfaces; on most clusters that means a compromised node agent or a privileged DaemonSet, not a plain tenant pod. 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

https://nvd.nist.gov/vuln/detail/CVE-2026-23213 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/

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.