AMD Zen 5 RDSEED (16-bit and 32-bit variants): On Zen 5, the 16-bit and 32-bit forms of RDSEED return zero far more

Impact

On Zen 5, the 16-bit and 32-bit forms of RDSEED return zero far more often than randomness allows, while still setting the carry flag to signal success. Any software that trusts RDSEED's success indicator - kernel entropy pools, TLS libraries, key generation inside confidential guests - silently consumes zeros as if they were seed material. This is a hardware entropy failure that announces nothing; you find it by auditing, not by observing symptoms.

Who can reach it

Not an attack in the usual sense - it is a silicon defect that any workload on affected Zen 5 parts hits passively. The exposure is that an attacker who knows a target derived keys from RDSEED on affected hardware can search a drastically reduced keyspace.

What to do

Fixed in the Linux kernel (x86/CPU/AMD) by masking off the broken RDSEED variants on affected Zen 5 parts, so the OS stops trusting them and falls back to working entropy sources. Take the distro kernel update and reboot the node; no firmware, microcode or BIOS step. Guest kernels need the same fix, so confidential-VM images must be updated too. Rotate any long-lived key material generated on affected Zen 5 hosts before the fix - the patch stops the bleeding but does not un-weaken existing keys.

References