AMD's Random Number Bug Is Older and Wider Than Its Fix

AMD's random-number generator has a second, unpatched problem beyond the one it acknowledged in October 2025: on at least two processor generations, the RDRAND and RDSEED instructions appear never to return a true zero at the requested bit width. A programmer posting as Jessé first reported it on the assembly-language forum flatassembler.net on May 11, 2026. Hacker News revived the thread on Sept. 22, and new testers reproduced it within hours.

What a hobbyist found on May 11

Jessé, who said he is based in Brazil, wrote that he found the anomaly by accident while building a chart-rendering program that called rdrand and rdseed on an AMD Ryzen 7 4800HS. "A true zero (fitting the requested size), on AMD, never happens," he wrote; the same code produced zeroes normally on an Intel chip. He built and published an open-source test tool, random-fryer, so others could check their own hardware.

AMD misread the results, then went quiet

By May 23, after nine days of continuous generation on two AMD systems, Jessé reported that not a single zero had appeared. AMD had replied to his report by then, but, he wrote, "it seems that the guy from their team misread my results entirely." The company escalated the case internally. The thread shows no further update from AMD in the four months that followed.

AMD's acknowledged bug is narrower, and already patched

AMD has confirmed a related but smaller problem. Security bulletin AMD-SB-7055, published Oct. 23, 2025, says the 16-bit and 32-bit forms of RDSEED on "Zen 5" processors can signal success, carry flag set to 1, while actually returning zero when the entropy buffer runs empty. AMD tracks that as CVE-2025-62626, rated 7.3 of 10 under CVSS 4.0, and says the 64-bit form is unaffected. It shipped microcode and AGESA fixes to OEMs between Oct. 28 and Dec. 26, 2025. The bulletin does not mention Zen 1, Zen 2, or the never-returns-zero pattern Jessé described, and credits the Linux kernel mailing list, not Jessé, as the source of the report it acted on.

Processor	Generation	Ever returns a true zero?
Ryzen 7 4800HS	Zen 2	No, per original May report
Ryzen 5 1600	Zen 1	No, reproduced Sept. 22
Ryzen 7 5700X	Zen 3	Yes, reported clear
EPYC 74F3	Zen 3	Yes, zeros observed
Ryzen 9 9950X3D	Zen 5	Yes (separate RDSEED bug, CVE-2025-62626)

New testers split on Zen 3, agree on Zen 5

Two testers who replied on Sept. 22 got different results on the same microarchitecture. A tester posting as Sellyme reproduced the never-zero pattern on a Ryzen 5 1600 and said a friend's Ryzen 7 5700X, also Zen 3, did not show it. A separate tester posting as matja ran random-fryer on an EPYC 74F3, also Zen 3, and reported both 16-bit and 32-bit zero values in the output, with more samples still being gathered. Sellyme's own Ryzen 9 9950X3D, a Zen 5 chip, generated zeroes normally on the never-zero test, but separately reproduced AMD's already-documented RDSEED bug.

The score covers one bug, not the one testers found

The 7.3 rating AMD assigned CVE-2025-62626 describes only the disclosed Zen 5 case, where entropy exhaustion is required and just two of three RDSEED operand sizes are affected. It says nothing about whether the broader pattern Jessé and this week's testers describe is a design choice, an undisclosed defect, or a sampling fluke that survived nine days of continuous generation on two chips. The instruction reference itself, quoted in the thread by a longtime forum member posting as revolution, specifies that RDRAND and RDSEED write zero and clear the carry flag on failure, but that a genuine zero is also a valid, if rare, output on success. That overlap is why an instruction that appears structurally unable to return zero is hard to prove without exactly this kind of high-volume test.

This kind of split disclosure has a recent parallel: lwIP's fixes for two critical bugs likewise predated CISA's public advisory by weeks. AMD's chips drew separate, unrelated scrutiny in September 2026, in independent transistor-budget testing of its X3D line.

AMD has not issued an advisory covering Zen 1 or Zen 2 processors, and there is no patch to apply for the pattern Jessé described. Software that relies on RDRAND or RDSEED for cryptographic keys can use the same workaround AMD lists for CVE-2025-62626: call the 64-bit form, or retry until the carry flag reports success on a non-zero value. Random-fryer remains the only public way to check whether a given AMD chip is affected, until AMD says otherwise.