AMD Secure Processor TEE SOC driver - SR-IOV GFX firmware load command: MULTI-TENANT ISOLATION: A malformed

Impact

MULTI-TENANT ISOLATION: A malformed DRV_SOC_CMD_ID_LOAD_GFX_IP_FW SR-IOV command causes an out-of-bounds read in the ASP's TEE SOC driver. This one matters specifically because it sits on the SR-IOV path - the mechanism by which a single GPU is carved up between virtual functions belonging to different tenants. A guest VF driver reaching a firmware-load command handler is precisely the boundary GPU virtualisation is supposed to hold.

Who can reach it

Reachable from an SR-IOV virtual function, i.e. from a guest VM that has been assigned a GPU VF - so this is guest-to-platform, not merely host-local. Only applies where GPU SR-IOV virtualisation is actually enabled.

What to do

Fixed in AMD reference firmware (AGESA / SEV firmware) and delivered to you only as an OEM SBIOS/BIOS package - Dell, HPE, Supermicro, Lenovo, Gigabyte and the ODMs each rebuild and requalify AMD's AGESA drop before it ships. **Expect months, not weeks**: AMD publishes the bulletin, the OEM ships BIOS somewhere between one and six months later, and for platforms past their support window it may never arrive at all. Applying it is a full node power cycle with the host drained - not a driver reload, not a live patch. Track it as a firmware campaign per server SKU, not per kernel version, and verify afterwards by reading back the SMU/PSP firmware version rather than trusting the BIOS revision string. If you run GPU SR-IOV with untrusted tenants in the VFs, this is worth prioritising over its 4.6 score; if you do passthrough of whole physical GPUs instead, the path is not exercised.

References