AMD processors with SMT - speculative execution across SMT mode switch: With SMT enabled, certain AMD processors

CVSS 4.7CVE-2022-27672Firmware, BMC & network fabricCross-Thread Return Address Predictionscurated

Impact

With SMT enabled, certain AMD processors speculatively execute using a branch target supplied by the sibling thread after an SMT mode switch. One hardware thread therefore steers the other's speculation - a Spectre-v2-shaped attack that crosses the thread boundary rather than the process boundary, so it defeats isolation between two tenants sharing a physical core even when they are in different VMs.

Who can reach it

Local, requires SMT enabled and attacker/victim on sibling threads of the same core - the default arrangement on a bin-packed cluster.

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. The zero-cost mitigation available today is scheduling policy rather than patching: these attacks need the attacker and victim co-resident on sibling SMT threads, so either disable SMT (costing roughly 10-25% throughput on most inference and training workloads) or enforce core isolation so no two tenants ever share a physical core. On a GPU fleet the CPU is rarely the bottleneck, which makes disabling SMT a cheaper trade than it looks on paper.

References

https://nvd.nist.gov/vuln/detail/CVE-2022-27672 https://www.amd.com/en/resources/product-security.html

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.