AMD CPU microcode - bound check: MULTI-TENANT ISOLATION: An improper bound check inside AMD CPU microcode lets

Impact

MULTI-TENANT ISOLATION: An improper bound check inside AMD CPU microcode lets a malicious **guest** write into host memory. This is a straight VM-escape primitive expressed in silicon microcode rather than in the hypervisor: the tenant does not need a QEMU or KVM bug, the CPU itself lets the write through. Once a guest can write host memory the host is compromised, and from there every other VM on the box.

Who can reach it

From inside a guest VM - no host privilege required. That makes this materially more dangerous operationally than the local-admin microcode issues: your tenants are the attackers in the threat model.

What to do

Fixed by an AMD microcode patch. Two delivery routes, and the difference matters: the linux-firmware amd-ucode blobs load early at boot (initramfs) and need only a reboot, while the durable fix is the microcode embedded in the OEM SBIOS/AGESA package, which carries the usual one-to-six-month OEM lag and a full power cycle. **For confidential computing you need the SBIOS route**: microcode late-loaded by the OS is not part of what SEV-SNP attests, so a guest checking the attestation report cannot tell the fix is present. AMD does not support late-loading microcode on a running EPYC host - treat this as reboot-required. After patching, expect the reported TCB version to change and plan the VCEK certificate refresh accordingly. Prioritise this above the local-admin microcode issues on any node that runs untrusted guest VMs - the attacker prerequisite here is simply 'is a tenant'.

References