Database/Control plane, storage & DevOps
AMD IOMMU host buffer access - insufficient RMP checks (AMD-SB-3016): MULTI-TENANT ISOLATION: Insufficient RMP checking
Impact
MULTI-TENANT ISOLATION: Insufficient RMP checking on IOMMU host buffer access produces an out-of-bounds write. This is the most operationally expensive item in the RMP family, because of what fixing it costs rather than what it does.
Who can reach it
Privileged attacker with hypervisor control, via IOMMU host buffer operations.
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. **This one needs more than a BIOS flash**: AMD requires the firmware update, an OS update, *and* a full SNP guest shutdown and platform re-initialization. In practice that means draining every confidential VM off the host, tearing down SNP, updating, re-initializing and re-admitting - a materially longer maintenance window than the rest of the batch, and one you cannot overlap with normal rolling reboots. Plan capacity for it explicitly.
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.