AMD Power Management Firmware (PMFW) - guest VM input validation causing GPU reset: MULTI-TENANT ISOLATION: Improper

Impact

MULTI-TENANT ISOLATION: Improper input validation in AMD's GPU Power Management Firmware lets a **guest VM** send arbitrary input data that forces a GPU reset. On a virtualised GPU host this is a tenant taking the accelerator out from under everyone sharing it: a GPU reset kills in-flight work on the whole device, so one tenant's malformed PMFW message destroys other tenants' training progress since their last checkpoint. Cheap to trigger, expensive to absorb, and it does not require the attacker to escape their VM at all.

Who can reach it

From inside a guest VM with GPU access - SR-IOV virtual function or passthrough. No host privilege and no escape needed; the guest simply talks to the power management firmware through the interface it is legitimately given.

What to do

Fixed in AMD GPU firmware, which on Instinct parts is delivered as a firmware bundle through the ROCm/amdgpu driver package (the PSP loads the signed blobs at driver init) rather than through the server BIOS. Practically: update the AMD GPU driver/firmware package, then **drain the node and reboot** - the firmware is loaded once at driver init, so a reload of the module with no process holding /dev/kfd is the minimum, and a reboot is what you will actually schedule. Some fixes at this layer also require a **GPU VBIOS flash** via AMD's amdvbflash/amdfwtool, which is an offline, per-card operation with real bricking risk - check the AMD bulletin for whether a VBIOS update is called out before assuming a driver package covers it. Prioritise this on any GPU virtualisation deployment with untrusted tenants - the attacker prerequisite is just 'has a GPU assigned'. Interim mitigation is thin: you cannot easily filter PMFW messages from a VF, so the practical stopgap is not co-tenanting untrusted guests on a shared physical GPU until the firmware is updated.

References