Linux kernel amdgpu display core (DC/DM) (drm/amd/display): A race condition or locking defect in the amdgpu display

Impact

A race condition or locking defect in the amdgpu display core (DC/DM). 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/amd/display: fix page fault due to max surface definition mismatch

Who can reach it

Local. Reachable by a local user with access to the DRM primary node, or an attacker who controls the attached display's EDID/DisplayPort topology. On headless Instinct nodes the display block is largely unused, which cuts real exposure sharply. 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