AMD patches a critical microcode vulnerability affecting Zen 1 to Zen 4 EPYC CPUs

(Image credit: AMD)

Yesterday, AMD and Google publicly disclosed September findings of a key microcode vulnerability in AMD Zen 1 to Zen 4 CPUs, specifically server/enterprise platform EPYC CPUs. This vulnerability, CVE-2024-56161, is discussed in more detail in the GitHub post from the Google Security Research team and, of course, AMD's security bulletin on the vulnerability.

According to Google's documentation, the original issue was reported on September 25, 2024, and subsequently fixed by AMD about two and a half months later, on December 17, 2024. The public disclosure date was delayed until yesterday, February 3, to give AMD's customers time to apply the fix before the issue became more widespread.

SEV refers to Secure Encrypted Virtualization, a feature used by server-grade AMD CPUs to allow virtualization. This usually means remote or on-site "thin clients" whose data is stored and managed in a central server. The devices they use to access it are so secondary that they sometimes have little to no processing power. The specific setup can vary. Still, the purpose of virtualizing several users is typically to save on hardware costs or provide a higher degree of security—sometimes both.

The specific series of impacted AMD EPYC CPUs include the following: AMD EPYC 7001 (Naples), AMD Epyc 7002 (Rome), AMD Epyc 7003 (Milan and Milan-X), and AMD Epyc 9004 (Genoa, Genoa-X, and Bergamo/Siena). Microcode updates have fortunately already been released for impacted CPUs, so using the appropriate update utilities (BIOS updates, etc.) should work fine— but as AMD notes, a SEV firmware update may be required for some platforms to support the fix via SEV-SNP attestation properly.

See more CPUs News

TOPICS

Christopher Harper has been a successful freelance tech writer specializing in PC hardware and gaming since 2015, and ghostwrote for various B2B clients in High School before that. Outside of work, Christopher is best known to friends and rivals as an active competitive player in various eSports (particularly fighting games and arena shooters) and a purveyor of music ranging from Jimi Hendrix to Killer Mike to the Sonic Adventure 2 soundtrack.

1 Comment Comment from the forums

edzieba

This is an "It's much, MUCH worse than you thought" vulnerability.
The article skips over the main impact of this vulnerability, which is to allow arbitrary microcode installation. The researchers proof-of-concept was to make RDRAND always return "4", which would render all encryption on that CPU trivially breakable.
And because its microcode, it's resident in the CPU BIOS chip rather than an exploit that needs to be run at the target's premises. A bad actor could buy up a pile of CPUs motherboards, install a custom malicious microcode onto them, and then resell them - or worse, return them with a fake seal to a major distributor (e.g. Amazon) and flood the supply chain with trojan horses. And because the fix is itself a microcode update, every single motherboard that has not installed the most recent microcode update (e.g. basically every motherboard still in stock for sale today) is vulnerable out of the box, and the first feature I'd add to my malicious custom microcode would be a function to look for attempted microcode updates, not apply them, then report the update being applied successfully and increment the version number reported to the host.
Reply