AMD Zen microcode patch loader (CPU ROM signature verification): The CPU ROM's microcode patch loader verified patch

Impact

The CPU ROM's microcode patch loader verified patch signatures using AES-CMAC with a published example key, so an attacker with local administrator privilege can sign and load their own microcode onto Zen 1 through Zen 4 CPUs. Loading arbitrary microcode means redefining what x86 instructions do - the attacker can make RDRAND return a constant, disable checks, or backdoor the CPU beneath every layer of software. For a confidential-computing operator this is the ballgame: SEV-SNP's entire guarantee rests on the CPU behaving as specified, so a host administrator can now read and tamper with any SEV-SNP guest's memory while the attestation report still looks clean. Google's security team demonstrated the full chain.

Who can reach it

Local, requires ring-0 / host administrator privilege. Not remote, and not reachable from a tenant container. But 'host administrator' is exactly the adversary SEV-SNP exists to exclude, which is why a local-admin bug is a confidential-computing catastrophe rather than a routine escalation. Persistence note: microcode does not survive a power cycle, so an attacker must reload it each boot - which also means a cold boot clears an implant.

What to do

Fixed by an AMD microcode patch. Two delivery routes, and the difference matters: the linux-firmware amd-ucode blobs load early at boot (initramfs) and need only a reboot, while the durable fix is the microcode embedded in the OEM SBIOS/AGESA package, which carries the usual one-to-six-month OEM lag and a full power cycle. **For confidential computing you need the SBIOS route**: microcode late-loaded by the OS is not part of what SEV-SNP attests, so a guest checking the attestation report cannot tell the fix is present. AMD does not support late-loading microcode on a running EPYC host - treat this as reboot-required. After patching, expect the reported TCB version to change and plan the VCEK certificate refresh accordingly. Specifically: AMD shipped fixed microcode plus an updated ASP bootloader in AGESA (December 2024 / released publicly February 2025). Zen 1-4 EPYC and Ryzen are affected; Zen 5 is not. The critical operator step people skip is the attestation side - after the TCB bump, refresh VCEK certs and require tenants to pin the new minimum TCB, otherwise you are patched but still accepting attestations that would have been valid on a backdoored host.

References

Related entries

• AMD CPU microcode patch loading - improper cleanup: Improper cleanup during microcode patch loading gives a localCVE-2025-0032 · AMD CPU microcode patch loading - improper cleanupHigh
• Supermicro BMC firmware validation logic on the X12STW-F motherboard: An attacker with administrative reach to the BMCCVE-2025-12006 · Supermicro BMC firmware validation logic on the X12STW-F motherboardHigh
• Intel CSME firmware (TOCTOU): A time-of-check/time-of-use race in CSME firmware lets a privileged local user escalateCVE-2025-20037 · Intel CSME firmware (TOCTOU)High
• Intel Xeon processor firmware (SGX enabled): Improper buffer restrictions in Xeon firmware on SGX-enabled parts, givingCVE-2025-20053 · Intel Xeon processor firmware (SGX enabled)High
• Intel Xeon 6 memory subsystem (with SGX or TDX): An out-of-bounds write in the Xeon 6 memory subsystem reachable whenCVE-2025-26403 · Intel Xeon 6 memory subsystem (with SGX or TDX)High
• Intel Xeon 6 DDRIO configuration (with SGX or TDX): An improperly implemented security check in DDRIO configuration onCVE-2025-32086 · Intel Xeon 6 DDRIO configuration (with SGX or TDX)High