Database/Kernel, userspace & hypervisor
AMD SEV-SNP (BadRAM): BadRAM: improper validation of DIMM SPD metadata lets an attacker with physical access or ring0
Impact
BadRAM: improper validation of DIMM SPD metadata lets an attacker with physical access or ring0 on a non-compliant DIMM overwrite guest memory and forge SNP attestation
Who can reach it
Physical access / compromised host firmware against a confidential tenant VM
What to do
AGESA/BIOS firmware update + reboot, plus DIMM SPD lockdown at the supply-chain level. Cannot be fixed in software - a genuine constraint on any "we cannot see your data" confidential-GPU claim
Fleet impact
How widespread
common - 3rd/4th-gen EPYC (Milan, Milan-X, Genoa, Bergamo, Genoa-X, Siena) hosts under GPU nodes
Cost to remediate
firmware-flash - AMD's fix validates SPD metadata at boot, so it is a BIOS/AGESA update per node; the underlying attack needs ~$10 of hardware and physical access, which colo and bare-metal-rental models do not exclude
Why it hits the whole fleet
Forges SEV-SNP attestation reports and inserts undetectable backdoors into confidential VMs, i.e. every attestation a customer verified on affected hosts is retroactively meaningless.
References
This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.