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

[Admin]

A vulnerability targeting AMD CPUs that can execute unsigned microcode on your processor also affects AMD's Zen 5.

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

 

[bit_user]

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.

 

[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?

 

[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.

 

[bit_user]

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.

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.

 

[bit_user]

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.

 

[thunderbolt17]

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?

 

[bit_user]

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.

 

[edzieba]

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.

 

[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.

 

[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.

 

[bit_user]

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.

It's one of the more esoteric vulnerabilities. You probably should be more worried about run-of-the-mill malware and viruses.

For that:

• keep up-to-date on OS & software updates (esp. web browser)
• change the default password on your router and keep its firmware updated
• don't click links in strange emails
• don't install cheat software or cracks for copy protection, as these are often infected
• don't insert random USB sticks in your PC
• use an antivirus program

 

[NotKenBlock]

It's one of the more esoteric vulnerabilities. You probably should be more worried about run-of-the-mill malware and viruses.

For that:

• keep up-to-date on OS & software updates (esp. web browser)
• change the default password on your router and keep its firmware updated
• don't click links in strange emails
• don't install cheat software or cracks for copy protection, as these are often infected
• don't insert random USB sticks in your PC
• use an antivirus program

So pretty much everything I'm doing already that should be common sense, got it. Thank you for taking the time to reply, I appreciate it!