AMD CPUs - attacker influence over RDSEED entropy: MULTI-TENANT ISOLATION: A local attacker can influence the values

Impact

MULTI-TENANT ISOLATION: A local attacker can influence the values RDSEED returns, causing consumers to draw insufficient entropy. Anything on the node that seeds a key, nonce or token from the hardware RNG - including confidential guests that deliberately chose the hardware source because they do not trust the host - gets attacker-influenced material. The failure is silent: the instruction reports success, and nothing downstream can tell the difference until someone else predicts the key.

Who can reach it

Local. The attacker influences entropy consumed by other software on the same machine, including guests.

What to do

Mitigated by AMD microcode plus, on most of these, a kernel-side change - and the durable delivery vehicle is the OEM SBIOS/AGESA package, which carries **one to six months of OEM lag** and needs a drained node and a full power cycle. The linux-firmware amd-ucode blobs get you the microcode sooner via initramfs early-load and a reboot, but AMD does not support late-loading microcode on a running EPYC host, so either way this is reboot-required, not a live patch. Also update guest and host kernels so the OS entropy pool does not lean solely on RDSEED. Any long-lived key generated on an affected host before patching should be rotated - the fix protects future output, not keys already derived.

References