AMD processors - transient non-canonical loads and stores using lower 48 address bits: MULTI-TENANT ISOLATION: Combined

Impact

MULTI-TENANT ISOLATION: Combined with specific software sequences, AMD CPUs transiently execute non-canonical loads and stores using only the lower 48 address bits - so an access that should fault instead speculatively reads a truncated address. That truncation can land inside another security domain's memory, and the result is observable through the usual cache channels. Data leakage across the boundaries the address canonicality check was supposed to enforce.

Who can reach it

Local, needs the victim to contain a specific software sequence, so exploitability depends on what is running - but on a shared node you do not control what your tenants run.

What to do

Mitigated by AMD microcode plus, on most of these, a kernel-side change - and the durable delivery vehicle is the OEM SBIOS/AGESA package, which carries **one to six months of OEM lag** and needs a drained node and a full power cycle. The linux-firmware amd-ucode blobs get you the microcode sooner via initramfs early-load and a reboot, but AMD does not support late-loading microcode on a running EPYC host, so either way this is reboot-required, not a live patch. Kernel-side mitigations exist for the known sequences; take the distro kernel update as well as the firmware.

References