AMD confirms security vulnerability on Zen 5-based CPUs that generates potentially predictable keys — RDSEED fix coming through an AGESA firmware update for desktop chips
RDSEED failures are incorrectly being flagged as correct, leading to potentially predictable encryption keys being generated by the random number generator.
AMD has confirmed the existence of RDSEED failure on CPUs based on its latest Zen 5 architecture, a critical security vulnerability in its hardware-based random number generator. The company has confirmed the fault could lead to the random number generator putting out keys that aren't fully unpredictable, opening up a vulnerability to users.
AMD is labeling the fault "AMD-SB-7055" and classifying it as a high-severity issue. Mitigations for the issues are rolling out now through January 2026, depending on the CPU mode. For instance, AMD has already rolled out mitigations of the issue for EPYC 9005 CPUs. Mitigations for AMD's consumer-based Zen 5 chips, including the Ryzen 9000 series, AI Max 300 series, Threadripper 9000 series, and Ryzen Z2 series, are coming out on November 25th.
The failure specifically involves the RDSEED instruction on Zen 5 chips returning "0" in a non-randomized manner and signaling the failure incorrectly as a success. The 16-bit and 32-bit formats of the RDSEED instruction are affected, while the 64-bit version is reportedly not affected by the issue for reasons AMD did not specify.
This is a critical issue for cryptography applications that rely on RDSEED's random number generation capabilities to provide fully unpredictable cryptography keys. If RDSEED fails, applications using it are at risk of attacks if the failure leads to a character pattern that is predictable.
RDSEED is one of two random key generation systems available on modern CPUs (including Intel chips). RDSEED is a true random-number generator and generates numbers by collecting entropy from the environment and storing a random bit pattern into a CPU register. RDRAND is faster but provides a random pattern from a deterministic random-number generator instead, which can be more predictable.
The issue was first discovered by a Meta engineer, who announced the issue on the Linux kernel mailing list (Phoronix reported in mid-October). The issue was not only the same as what AMD confirmed above, but was reliably reproducible by hammering RDSEED with one CPU thread and another thread "collectively eating and hammering on ~90% of memory..." A few days later, an updated Linux patch was posted that would disable RDSEED on all Zen 5 chips to stop the security vulnerability.
This isn't the first time RDSEED has proven problematic on Zen-based processors. Cyan Skillfish, AMD's Zen 2-based APUs, also suffered from a similar (but different) RDSEED failure that also forced the Linux community to disable RDSEED functionality on those chips.
Get Tom's Hardware's best news and in-depth reviews, straight to your inbox.
Thankfully, AMD will have AGESA microcode updates out soon to rectify this issue across all Zen 5 CPUs. In the meantime (for chips that don't have the mitigation yet), AMD recommends its users switch to its unaffected 64-bit form of RDSEED or switch to a software fallback.
Follow Tom's Hardware on Google News, or add us as a preferred source, to get our latest news, analysis, & reviews in your feeds.
Aaron Klotz is a contributing writer for Tom’s Hardware, covering news related to computer hardware such as CPUs, and graphics cards.
-
JRStern >hardware-based random number generatorReply
Kinky. How long has this been going on?
Computer processors have offered hardware-based random number generators since at least 1951 with the Ferranti Mark 1, which used electrical noise to generate random bits. However, more modern, widely available on-chip hardware random number generators like Intel's RDRAND instruction were introduced much later, starting around 2012 with the Ivy Bridge architecture, with AMD adding support in 2015.
Hah! Who knew, not me.
I did test out Microsoft's random number generator API a few years back and was pretty amazed, I didn't test its randomness but at least I was able to generate millions without a duplicate. Didn't know it was done with hardware support but looks like it would have been. -
DS426 Two questions for the Linux community: why wouldn't devs switch the Linux kernel to forced used of 64-bit RDSEED instead of disabling it entirely on Zen 5? What is used as the next-in-line alternative as a truly random number seed generator?Reply
Just curious. -
DS426 Reply
It gets even more sexy when they starting talking about entropy.JRStern said:>hardware-based random number generator
Kinky. How long has this been going on?
Hah! Who knew, not me.
I did test out Microsoft's random number generator API a few years back and was pretty amazed, I didn't test its randomness but at least I was able to generate millions without a duplicate. Didn't know it was done with hardware support but looks like it would have been. -
JRStern Reply
Yah. I know some about this, and some small amount about encryption keys, and have been noodling around prime numbers for the last week. There is some strange and wonderful stuff floating around, that people have done. If your keys are so long, and so hard to break, then why do they have to be random, too? I don't care so much about crypto, my main concern was generating globally unique keys, a somewhat different game, but hey.DS426 said:It gets even more sexy when they starting talking about entropy. -
DS426 Reply
Long keys and hard to break are two different things. Long numbers or character strings are hard to guess using brute force. Keys are hard to break when they are both long and their seed is unpredictable. If you can predict the seed, you can calculate the long number or character string of the key just as cryptography uses in the first place to initially generate the key. If the seed is unpredictable due to high entropy, you're able to have proper crypto, such as the Public Key Cryptography like TLS (previously SSL) that secures data across the dangerous internet.JRStern said:...If your keys are so long, and so hard to break, then why do they have to be random, too?...
If you're just looking to get a random value from whatever input and don't need reversible encryption, you can use something like SHA256 or higher to generate a character string from a file or whatever binary object. As long as the binary data is different, the result will always be different (ignoring collisions which become exponentially less likely for longer SHA functions like SHA512). Just be aware it's a deterministic function.
Might not be practical for what you're trying to do but just some food for thought. -
phxrider What does this affect that the average person would use (not cryptography developers)?Reply
Not arguing against keeping chipset drivers up to date, just determining what the rational freak-out level is.