AMD SEV-ES - bounds checking on Reverse Map table memory: MULTI-TENANT ISOLATION: Insufficient bounds checking

Impact

MULTI-TENANT ISOLATION: Insufficient bounds checking in SEV-ES lets an attacker corrupt Reverse Map table memory, breaking SEV-SNP memory integrity. The RMP is the single data structure that decides which physical page belongs to which guest; corrupting it is the most direct possible attack on confidential-VM isolation, because after that the hardware itself believes the wrong owner.

Who can reach it

Host/hypervisor-privileged attacker.

What to do

Fixed in AMD reference firmware (AGESA / PSP / SEV firmware) and delivered only as an OEM SBIOS/BIOS package - Dell, HPE, Supermicro, Lenovo and the ODMs each rebuild and requalify AMD's AGESA drop before shipping. **Expect one to six months of OEM lag**, and on end-of-support platforms expect nothing. Applying it is a drain plus full power cycle, not a driver reload. Verify by reading back the PSP/SMU firmware version afterwards rather than trusting the BIOS version string. This sits inside the SEV-SNP trust boundary, so the update moves the platform's reported TCB version: refresh VCEK certificates from AMD's KDS and update any attestation policy your tenants pin, or confidential guest launches will start failing right after the BIOS lands. Treat RMP-corruption issues as the top tier of your SEV patch queue - everything else in SNP rests on the RMP being correct.

References