Zenbleed: AMD CPU Vulnerability Leaks Data Across Processes (CVE-2023-20593)

On July 24, 2023, Google security researcher Tavis Ormandy publicly disclosed Zenbleed (CVE-2023-20593), a vulnerability in AMD Zen 2 processors that allows an attacker to steal sensitive data from other processes running on the same CPU core. The flaw exists at the hardware level and can be triggered from unprivileged userspace code—no root, no kernel module, no special permissions required.

What Is Zenbleed?

Zenbleed is a speculative execution vulnerability in AMD's Zen 2 microarchitecture. It exploits a bug in the processor's handling of the vzeroupper instruction, which is used to zero out the upper 128 bits of AVX (Advanced Vector Extensions) registers.

Here's the short version: due to a flaw in the speculative execution pipeline, an attacker can cause the CPU to expose register data from other processes. The data leaked includes anything that happens to pass through the CPU's vector registers—which, thanks to compiler optimizations, includes a surprising amount of sensitive information like encryption keys, passwords, and user data.

Ormandy's proof of concept demonstrated data exfiltration at approximately 30KB per core per second. That's fast enough to capture keystrokes, passwords, and encryption keys in real time.

Affected Hardware

Every processor based on AMD's Zen 2 microarchitecture is affected:

• AMD Ryzen 3000 series (desktop)
• AMD Ryzen 4000 series (mobile, Renoir)
• AMD Ryzen 5000 series (mobile, Lucienne)
• AMD Ryzen 7020 series
• AMD EPYC 7002 series (Rome) — widely used in cloud data centers
• AMD Ryzen Threadripper 3000 series

The inclusion of EPYC 7002 "Rome" processors is particularly concerning. These chips power a significant portion of cloud infrastructure at providers like AWS, Azure, and Google Cloud. In multi-tenant cloud environments, a malicious VM could potentially read data from other VMs or processes on the same physical core.

Technical Deep Dive

The vulnerability centers on a microarchitectural optimization gone wrong. Here's what happens:

1. The CPU speculatively executes a vzeroupper instruction
2. During the speculative window, the CPU incorrectly handles register file state
3. If the speculation is rolled back (mispredicted), the physical register mapping is left in an inconsistent state
4. A subsequent operation can read data from a physical register that was previously used by another process

The key insight is that the CPU's register renaming mechanism—which maps architectural registers to physical registers—doesn't properly clean up after a mispredicted vzeroupper. The physical register retains data from a previous process, and that data becomes accessible.

Ormandy's exploit is elegantly simple. The core loop fits in just a few lines of assembly:

vcvtsi2ss xmm, xmm, eax    ; Trigger use of YMM register
vmovupd ymm, ymm             ; Read the register
vzeroupper                    ; Trigger the bug

By repeating this pattern in a tight loop and monitoring the values that appear, the attacker can capture data from other processes sharing the same physical core.

Mitigations

AMD released microcode updates to fix Zenbleed, but the rollout was staggered:

• EPYC 7002 "Rome": Microcode update available at disclosure (July 2023)
• Desktop Ryzen 3000: Microcode update scheduled for December 2023
• Mobile processors: Various dates through December 2023

For systems that couldn't immediately apply microcode updates, AMD provided a software workaround: setting a specific model-specific register (MSR) bit (DE_CFG[9]) that disables the vulnerable optimization. This workaround has a performance impact, as it disables the speculative optimization entirely.

Linux distributions began shipping updated microcode packages within days of disclosure. However, the fix requires either a BIOS update from the motherboard manufacturer or a microcode update loaded at boot time by the operating system.

Cloud Impact

The cloud implications of Zenbleed are significant. AMD EPYC 7002 processors are deployed across major cloud providers. In theory, a malicious tenant could exploit Zenbleed to read data from co-located workloads on the same physical core.

Major cloud providers responded quickly:

• Google Cloud: Applied microcode updates to affected infrastructure promptly
• AWS: Updated affected EC2 host firmware
• Azure: Applied mitigations to Zen 2-based infrastructure

However, the episode raised uncomfortable questions about hardware-level vulnerabilities in shared infrastructure. Unlike software vulnerabilities, hardware bugs can't be patched in the traditional sense—they require microcode updates that may carry performance penalties, and the underlying silicon flaw persists.

Context: The Speculative Execution Era

Zenbleed joins a growing family of speculative execution vulnerabilities that began with Spectre and Meltdown in January 2018. Each generation of discoveries has revealed new ways that performance optimizations in modern CPUs can be abused to leak data across security boundaries.

What makes Zenbleed particularly concerning is its simplicity. Unlike some Spectre variants that require precise timing and complex gadgets, Zenbleed can be triggered with a few lines of code from unprivileged userspace. There's no need for a kernel exploit or elevated privileges.

How Safeguard.sh Helps

Safeguard.sh tracks hardware vulnerabilities alongside software vulnerabilities in your infrastructure inventory. Our platform monitors microcode versions across your fleet, alerts you when hardware CVEs like Zenbleed affect processors in your environment, and tracks remediation status across cloud and on-premise deployments. By including hardware and firmware in your Software Bill of Materials, Safeguard.sh ensures that vulnerabilities below the software layer don't fall through the cracks of your vulnerability management program.