Linux kernel amdgpu firmware, ACPI and IP-block initialisation (drm/amdgpu): A memory or reference-count leak

Impact

A memory or reference-count leak in the amdgpu firmware, ACPI and IP-block initialisation. Each pass through the affected path drops an allocation or a refcount on the floor. A tenant that loops the operation drives the node into memory exhaustion or pins objects that can never be freed, which on a long-lived GPU host shows up as creeping unreclaimable memory, failed allocations for other tenants, and eventually an OOM kill or a driver that will not unbind. Refcount leaks that wrap can also degrade into use-after-free. Upstream fix: drm/amdgpu: Fix memory leak in amdgpu_acpi_enumerate_xcc()

Who can reach it

Local. Reachable by a local user with driver-load influence, or an attacker who controls platform ACPI tables / VBIOS content - usually root or firmware-level access rather than a tenant. 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