AMD Secure Processor bootloader - legacy recovery mode: Insufficient input sanitisation in the ASP bootloader's legacy

Impact

Insufficient input sanitisation in the ASP bootloader's legacy recovery path lets an attacker write out of bounds and corrupt Secure DRAM, bricking the boot flow. The outcome is denial of service at the firmware level - a node that will not come back up, which on a GPU fleet means an RMA-shaped hole rather than a reboot.

Who can reach it

Local, and only through legacy recovery mode - so it needs an attacker who can force the platform into recovery, which usually means firmware-level or physical access.

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. Where the platform allows it, disabling legacy ASP recovery mode in SBIOS removes the reachable path without waiting for the OEM.

References