AMD SEV-SNP guest context page - use-after-free enabling migration-agent masquerade (AMD-SB-3002): MULTI-TENANT

Impact

MULTI-TENANT ISOLATION: A use-after-free in the SNP guest context page lets a malicious hypervisor masquerade as the guest's migration agent. The guest then negotiates its migration with the attacker instead of a legitimate MA - which is to say it hands over the state that memory encryption existed to protect, voluntarily, to the party it was protecting itself from.

Who can reach it

Malicious or compromised hypervisor. Only exercised where SEV-SNP live migration is enabled.

What to do

Fixed in AMD PI/AGESA firmware and delivered only as an OEM SBIOS package - AMD ships the PI drop to Dell, HPE, Supermicro, Lenovo and the ODMs, who each requalify before releasing BIOS. **Budget one to six months of OEM lag**, and note that several CVEs in this batch are marked 'no fix planned' on Naples (EPYC 7001) - for those the only remediation is retiring the hardware. Applying it means cordon, drain and a full power cycle per node; there is no driver reload, no live patch and no VBIOS step. Because this touches the SEV-SNP trust boundary, the update moves the platform TCB version: refresh VCEK certificates from AMD's KDS and update tenant attestation policy, or confidential guest launches will fail immediately after the BIOS lands. If you do not offer live migration for confidential VMs, the path is unreachable and this can wait for the next firmware wave. If you do, disable it until the fleet is patched - that is a scheduler policy change, not a maintenance window.

References