AMD Zen 5 CPUs also affected by microcode vulnerability — Granite Ridge, Turin, Ryzen AI 300, and Fire Range at risk

News
By published

You might want to update your BIOS.

Ryzen 9000 CPU
(Image credit: AMD)

Last month, the Google Security Team identified a security vulnerability in AMD's CPUs ranging from Zen 1 to Zen 4 dubbed "EntrySign" that allowed malicious users with ring 0 access to load unsigned microcode patches. An update to the AMD security bulletin now adds Zen 5, in all its forms across server and mainstream product lines, to the list of impacted infrastructures.

The security flaw leverages an improper signature verification in AMD's microcode patch loader, allowing third parties to execute arbitrary microcode on your processor.

EntrySign (ID: AMD-SB-7033) targets your CPU's microcode, which are low-level instructions that essentially bridge the gap between machine code (binary) and the physical hardware. Your CPU ships with a base microcode from the factory, embedded in its Read-Only Memory (ROM), and is immutable. Now, in case a vulnerability is found after the CPU starts retailing, manufacturers like Intel and AMD can simply push out a new microcode as a fix (take the Raptor Lake instability case, for instance).

While it is true that the CPU's built-in microcode cannot be changed, modern Operating Systems or your system's firmware (BIOS/UEFI) can load microcode updates during the early boot stages. This patch only lasts for the duration of that specific session, however.

Exposing a weakness in AMD's hashing algorithm, EntrySign can bypass the signature validation process and execute potentially unsafe microcode. The vulnerability stems deeper in servers, and is capable of compromising AMD's SEV/SEV-SNP technologies (ID: AMD-SB-3019) — potentially resulting in unauthorized access to data from virtual machines.

The primary requirement is access to ring 0, or kernel-level privileges, on the target system. Likewise, these patches do not persist after a system restart, dialing down the security alarm a notch. More creative/academic avenues open up in turn, such as a challenge at the RVSPOC (RISC-V Software Porting and Optimization Championship) 2025 that tasks contestants with running RISC-V binaries on Zen-based hardware, by leveraging this exploit to load custom microcode.

All Zen 5 CPUs, including Ryzen 9000 (Granite Ridge), EPYC 9005 (Turin), Ryzen AI 300 (Strix Halo, Strix Point, Krackan Point), and Ryzen 9000HX (Fire Range) processors are prone to this vulnerability. AMD has already deployed the ComboAM5PI 1.2.0.3c AGESA firmware for motherboard makers as a fix, so keep an eye on your vendor's website for an upcoming BIOS update. The mitigation addressing the SEV vulnerability counterpart hasn't been released yet for EPYC Turin — though it's scheduled for release sometime later this month.

See more CPUs News
Hassam Nasir
Hassam Nasir
Contributing Writer

Hassam Nasir is a die-hard hardware enthusiast with years of experience as a tech editor and writer, focusing on detailed CPU comparisons and general hardware news. When he’s not working, you’ll find him bending tubes for his ever-evolving custom water-loop gaming rig or benchmarking the latest CPUs and GPUs just for fun.

12 Comments Comment from the forums
  • bit_user
    The article said:
    More creative/academic avenues open up in turn, such as a challenge at the RVSPOC (RISC-V Software Porting and Optimization Championship) 2025 that tasks contestants with running RISC-V binaries on Zen-based hardware, by leveraging this exploit to load custom microcode.
    Wow, that's nuts! There's an English version of that page. The menu to switch the language is in the upper-right corner.

    So, they're not asserting that you can modify the microcode enough to natively execute RISC-V code, but they challenge contestants to devise microcode modifications that would at least make the code run more efficiently, without stipulating exactly what those are.
    Reply
  • thunderbolt17
    How exactly BIOS update is going to help? What prevents people from creating a malicious fake microcode that will report a version number of the "official" "fixed" microcode, and installing it on some CSP servers?
    Reply
  • hotaru251
    The primary requirement is access to ring 0, or kernel-level privileges, on the target system.


    if target has ring 0 access you already have a much larger concern.
    Reply
  • bit_user
    thunderbolt17 said:
    How exactly BIOS update is going to help?
    It will load a fix to the vulnerability, so that compromised microcode cannot be loaded in a subsequent part of the boot or during system operation.

    thunderbolt17 said:
    What prevents people from creating a malicious fake microcode that will report a version number of the "official" "fixed" microcode, and installing it on some CSP servers?
    If someone can hack CSP servers' BIOS, so that it loads infected microcode, and then somehow use that exploit to block installation of the proper BIOS, then obviously that's a problem. It's also not easily done, so hopefully they update their BIOS before someone figures out how to do that.
    Reply
  • bit_user
    hotaru251 said:
    if target has ring 0 access you already have a much larger concern.
    Actually, no. In a hypervisor environment, which uses memory encryption for the tenants, the host OS or hypervisor cannot normally spy on the tenants. Therefore, someone with ring 0 access to the host can certainly halt VMs or starve them of cycles, but the damage they can do to tenants is somewhat limited - they can't see what the tenant is doing or interfere in any sort of targeted way.

    However, if you can load custom microcode, then you can compromise the encryption mechanism used to guard tenant privacy. Then, you could indeed spy on them or interfere in more nefarious and subtle ways in their execution. That's because the CPU uses one set of microcode across all execution domains.
    Reply
  • thunderbolt17
    bit_user said:
    If someone can hack CSP servers' BIOS, so that it loads infected microcode, and then somehow use that exploit to block installation of the proper BIOS, then obviously that's a problem. It's also not easily done, so hopefully they update their BIOS before someone figures out how to do that.
    I am talking about a scenario where CSP itself is hacking its own BIOS and installing a custom microcode, which for example will allow it to spy on AMD-SEV confidential VM's. How can a VM trust an attestation report in that case, if it can be faked and report a version of "patched" microcode?
    Reply
  • bit_user
    thunderbolt17 said:
    I am talking about a scenario where CSP itself is hacking its own BIOS and installing a custom microcode, which for example will allow it to spy on AMD-SEV confidential VM's.
    Well, when they buy CPUs & motherboards new enough that they're shipping with fixed microcode, that will no longer be possible. For the time being, I guess you're right that a malicious and highly sophisticated CSP could indeed spy on your junk. And, unless there's some identifier they can't fake, like maybe a new instruction (which won't help until Zen 6 gets here), I suppose you have no way of knowing for sure whether you're on hardware new enough that they couldn't have hacked it.

    IMO, if you have cause to be that paranoid, then maybe don't use cloud in the first place? If you can't make do with on prem, then use co-location and bring your own hardware.
    Reply
  • edzieba
    bit_user said:
    Well, when they buy CPUs & motherboards new enough that they're shipping with fixed microcode, that will no longer be possible.
    As long as you trust your supply chain to not be compromised. A covert BIOS-chip-reflash sometime between point of manufacture and point of delivery can now pwn your server without anything you can do about it.
    In the absence of this exploit, even a fiddled BIOS could not allow a VM host to break into encrypted VM memory. This is no longer the case.
    Reply
  • razor512
    I wish articles like this would include a simplified list of which AGESA versions patch the issue for each generation of impacted CPU.

    For example,

    Ryzen 9000 series: ComboAM5PI 1.2.0.3c
    But what about older impacted platforms?

    My main reason for this is because motherboard makers like releasing updates after major discoveries where AMD may release a fix for, but the bios update from the motherboard maker has a much older AGESA.
    For example, Asus pushed out an update to many X570 motherboards after these vulnerabilities were published. They rarely ever give much detail, thus no simple at a glance way of knowing if ComboV2 PI 1.2.0.E has the fix or not.
    Reply
  • NotKenBlock
    Would someone mind explaining how exactly a person might become affected by this? I'm not particularly tech-savvy and, while I just stick to gaming and YouTube the majority of the time, I would like to know how to avoid this.
    Reply