AMD Confirms Zen 5 RNG Flaw: When ‘Random’ Isn’t Random Enough

by George Whittaker

on November 6, 2025

AMD Confirms Zen 5 RNG Flaw: When ‘Random’ Isn’t Random Enough

AMD has officially confirmed a high-severity security vulnerability in its new Zen 5–based CPUs, and it’s a nasty one because it hits cryptography right at the source: the hardware random number generator.

Here’s a clear breakdown of what’s going on, how bad it really is, and what you should do if you’re running Zen 5.

What AMD Just Confirmed

AMD’s security bulletin AMD-SB-7055, now tracked as CVE-2025-62626, describes a bug in the RDSEED instruction on Zen 5 processors. Under certain conditions, the CPU can:

• Return the value 0 from RDSEED far more often than true randomness would allow

• Still signal "success" (carry flag CF=1), so software thinks it got a good random value

The issue affects the 16-bit and 32-bit forms of RDSEED on Zen 5; the 64-bit form is not affected.

Because RDSEED is used to feed cryptographically secure random number generators (CSPRNGs), a broken RDSEED can poison keys, tokens, and other security-critical values.

AMD classifies the impact as:

Loss of confidentiality and integrity (High severity).

How the Vulnerability Works (In Plain English)

What RDSEED Is Supposed to Do

Modern CPUs expose hardware instructions like RDRAND and RDSEED:

• RDRAND: Gives you pseudo-random values from a DRBG that’s already been seeded.

• RDSEED: Gives you raw entropy samples suitable for seeding cryptographic PRNGs (it should be very close to truly random).

Software like TLS libraries, key generators, HSM emulators, and OS RNGs may rely directly or indirectly on RDSEED to bootstrap secure randomness.

What’s Going Wrong on Zen 5

On affected Zen 5 CPUs:

• The 16-bit and 32-bit RDSEED variants sometimes return 0 much more often than a true random source should.

• Even worse, they simultaneously report success (CF=1), so software assumes the value is fine rather than retrying.

In cryptographic terms, this means:

• Entropy can be dramatically reduced (many key bits become predictable or even fixed).

• Keys or nonces derived from those values can become partially or fully guessable.

Security researchers and coverage from outlets like TechSpot and The Register warn that a determined attacker with access to public keys generated on a vulnerable system may be able to reconstruct the corresponding private keys, or at least drastically cut the search space.

Which CPUs Are Affected?

AMD says the bug affects Zen 5–based processors, including multiple product lines. Public reporting and AMD partners list at least:

• Ryzen 9000 (desktop)

• Ryzen AI Max 300 (mobile AI-focused APUs)

• Ryzen Threadripper 9000 (HEDT / workstation)

• Ryzen Z2 series (handheld / mobile gaming)

• EPYC 9005 (server CPUs – some already have fixes)

Board vendors (e.g., Supermicro) are also flagging systems with Zen 5-based platforms as impacted and waiting on microcode/BIOS updates that include AMD’s mitigation.

Exact coverage can vary by OEM, so you should check your motherboard or server vendor’s security notes if you’re unsure.

How Bad Is It, Really?

CVE-2025-62626 currently carries a CVSS score around 7.2 (High).

Key points on impact:

• Local attack surface An attacker generally needs local code execution (e.g., untrusted code running on the same machine, a compromised container, or malicious tenant in a shared environment). This isn’t a pure remote bug like a network worm.

• Cryptographic integrity and confidentiality at risk If your software uses the faulty RDSEED outputs directly or indirectly for:

  • TLS keys

  • SSH keys

  • Disk encryption keys

  • JWT signing keys

  • Code-signing keys ...then those secrets may be weaker than expected or, in worst cases, reconstructable by an attacker who sees the public side (e.g., certificates, signatures).

• Silent failure The really dangerous part: the instruction looks like it succeeded, so libraries don’t know they should retry. That makes the vulnerability subtle and hard to detect in the field.

So while this is not a remote RCE, it’s a serious cryptographic weakness, especially in multi-tenant, high-value systems (cloud workloads, PKI, HSM-like services).

How the Vulnerability Was Found

The issue first surfaced publicly on the Linux kernel mailing list, where a Meta engineer noticed strange RDSEED behavior on Zen 5 hardware—values of 0 appearing at rates inconsistent with true randomness.

That prompted:

• Quick investigation by kernel developers

• A temporary Linux mitigation that simply disables RDSEED on Zen 5, forcing software to fall back to other randomness sources

• AMD’s internal analysis and the publication of security bulletin AMD-SB-7055

This is also not AMD’s first RDSEED-related issue; similar problems were previously reported on some Zen 2 "Cyan Skillfish" APUs, which raises questions about regression testing around hardware entropy paths.

AMD’s Mitigation Plan & Timeline

AMD’s plan is centered around microcode (AGESA) updates distributed via motherboard/server vendors:

• EPYC 9005 (servers)

  • Patches have already started rolling out for many EPYC server CPUs.

• Consumer Zen 5 chips (desktop / HEDT / mobile)

  • Ryzen 9000, Ryzen AI Max 300, Threadripper 9000, Ryzen Z2:

    • Fixes targeted for November 25, 2025 via AGESA firmware updates.

• Full coverage

  • AMD and several OEMs expect most Zen 5 platforms to be mitigated by January 2026, depending on vendor release schedules.

Official Guidance from AMD

Until microcode fixes are installed, AMD explicitly recommends:

• Prefer the 64-bit RDSEED variant (unaffected), where possible

• Or fallback to software-based randomness / other entropy sources (e.g., kernel RNG, /dev/urandom, RDRAND-seeded DRBGs)

Linux kernel maintainers have already opted for the "nuclear" approach in some builds: disable RDSEED on Zen 5 entirely and let the OS RNG handle it.

What You Should Do Right Now

1. If You’re a Regular Desktop or Gaming User

• Check for BIOS/UEFI updates

  • Look for a new firmware from your motherboard vendor mentioning AGESA updates or AMD-SB-7055 / CVE-2025-62626.

• Install OS updates

  • Make sure your Linux distro or Windows install is fully updated; distros are already shipping microcode or kernel-level mitigation.

• For most home users, simply staying up-to-date with OS + BIOS will be enough. The risk is higher for people doing crypto-heavy or security-sensitive work (self-hosted PKI, custodial wallets, etc.).

2. If You Run Servers or Cloud Infrastructure

This is where it really matters.

• Inventory your Zen 5 systems

  • Identify EPYC 9005 and Zen 5 Ryzen/Threadripper boxes in your fleet.

• Track microcode/BIOS advisory timelines from your hardware vendors (Supermicro, Dell, HPE, etc.) referencing AMD-SB-7055.

• Prioritize hosts that generate or store cryptographic keys, e.g.:

  • TLS termination nodes

  • KMS/HSM-like services

  • Certificate authorities, signing servers

• Temporarily avoid using RDSEED directly in any in-house crypto code. Favor OS RNGs or proven libraries that have shipped mitigations.

3. If You Maintain Software or Crypto Libraries

• Audit your use of RDSEED:

  • If you call RDSEED directly on x86, add detection for Zen 5 and avoid 16/32-bit variants there.

  • Prefer 64-bit RDSEED or OS-provided CSPRNG APIs.

• Watch for updates from:

  • OpenSSL, BoringSSL, LibreSSL

  • Linux kernel RNG code

  • Language runtimes (Rust, Go, Java, .NET) that might touch RDRAND/RDSEED

4. Hardening & Monitoring

Even beyond this specific bug:

• Ensure keys can be rotated quickly if you suspect they were generated on vulnerable hardware.

• For long-lived certificates/keys created recently on Zen 5 hosts, consider re-issuing after microcode is applied, especially for high-value systems.

How This Fits in the Bigger Picture of CPU Security

Zen 5’s RDSEED issue arrives on the heels of other CPU-level problems:

• Transient Scheduler Attacks (TSA) — speculative side-channel attacks on AMD schedulers, enabling cross-context information leaks.

• VMSCAPE (CVE-2025-40300) — a new Spectre-style attack that lets a malicious VM steal data from the host on AMD Zen 1–5 and Intel Coffee Lake CPUs.

Taken together, 2025 is reinforcing a clear message:

Hardware isn’t a trusted black box anymore. CPU features involved in randomness and speculation are part of your threat model.

The Zen 5 RDSEED bug doesn’t leak secrets via side channels; instead, it quietly undermines cryptographic strength by sabotaging entropy generation.

Bottom Line

• Yes, AMD has confirmed a serious vulnerability in Zen 5’s RDSEED implementation (AMD-SB-7055 / CVE-2025-62626).

• It does not give an attacker magic remote access, but it does threaten the integrity and secrecy of cryptographic keys on affected systems.

• Microcode and firmware fixes are rolling out now through January 2026, but you should:

  • Apply OS and BIOS/UEFI updates as they land

  • Avoid relying directly on RDSEED 16/32-bit on Zen 5 in your own code

  • Consider re-issuing high-value keys once your systems are fully patched

George Whittaker is the editor of Linux Journal, and also a regular contributor. George has been writing about technology for two decades, and has been a Linux user for over 15 years. In his free time he enjoys programming, reading, and gaming.