AMD SEV-SNP - selective DMA write drops on host-induced faults: MULTI-TENANT ISOLATION: By inducing faults

Impact

MULTI-TENANT ISOLATION: By inducing faults, a high-privileged local attacker can selectively drop a confidential guest's DMA writes, costing SEV-SNP guest memory integrity. Selectivity is what makes this more than noise: an attacker who can choose *which* writes vanish can corrupt a computation in a targeted way - dropping a gradient update, a checkpoint write, or a log entry - rather than just breaking the VM.

Who can reach it

Local, high-privileged host attacker, against a confidential guest doing DMA.

What to do

Fixed in AMD SEV firmware / AGESA and reaches you as an OEM SBIOS package - AMD hands AGESA to Dell, HPE, Supermicro, Lenovo and the ODMs, who each requalify before shipping BIOS. **Budget one to six months of OEM lag**, longer on older platforms and sometimes never on end-of-support SKUs. Applying it means draining the host and doing a full power cycle. Because the fix moves the platform's reported SEV-SNP TCB version, you must also pull fresh VCEK certificates from AMD's Key Distribution Service and update any attestation policy your tenants pin - otherwise guests will start failing launch validation the moment the BIOS lands. Some SEV firmware can alternatively be staged from linux-firmware (amd/amd_sev_*.sbin) and committed via the ccp driver at boot, which is faster than waiting on BIOS - check whether your platform supports firmware hot-load before assuming the OEM is the only route. CVSS 1.8 badly undersells this for anyone whose product claim is 'the host operator cannot tamper with your workload'; rate it against your own trust story, not the score.

References