In July 2022, researchers from ETH Zurich disclosed Retbleed, a new speculative execution attack that undermines years of Spectre mitigations. Tracked as CVE-2022-29900 (AMD) and CVE-2022-29901 (Intel), this vulnerability affects processors going back over a decade and forces the industry to rethink how we defend against speculative execution attacks.
What Is Retbleed?
Retbleed belongs to the Spectre-BTI (Branch Target Injection) family, but with a critical twist. Previous Spectre mitigations focused on indirect jumps and calls. The industry adopted "retpolines" — a clever technique that replaces indirect branches with return instructions, which were assumed to be safe from speculation-based attacks.
Retbleed proves that assumption wrong. The attack demonstrates that return instructions can be exploited in the same way as indirect branches, effectively bypassing the retpoline defense that Linux, Windows, and other operating systems have relied on since 2018.
The Technical Details
The attack works by poisoning the Return Stack Buffer (RSB). Modern CPUs use the RSB to predict where return instructions will jump. When the RSB is empty or mispredicts, the CPU falls back to other prediction mechanisms — and that fallback is where things get dangerous.
On AMD Zen 1 and Zen 2 processors (manufactured between 2017 and 2019), when the RSB underflows, the CPU uses the Branch Target Buffer (BTB) for predictions. An attacker who can influence BTB entries can redirect speculative execution of return instructions to attacker-controlled gadgets, leaking sensitive data from kernel memory.
On Intel Core generation 6 through 8 (Skylake and related microarchitectures), a similar issue exists where deep call stacks can cause RSB mispredictions exploitable by an attacker.
The ETH Zurich team demonstrated they could leak kernel memory at approximately 219 bytes per second on Intel and 3.9 kilobytes per second on AMD — slow by network standards, but fast enough to extract cryptographic keys, passwords, and other sensitive data from memory.
Why This Matters for the Supply Chain
Hardware vulnerabilities like Retbleed have a cascading effect on software supply chain security. Consider the impact:
Kernel patches introduce performance overhead. The mitigations for Retbleed come with a performance penalty of 14-39% on AMD processors, according to Phoronix benchmarks. For build systems and CI/CD pipelines that run on affected hardware, this directly impacts development velocity.
Cloud infrastructure is shared. In multi-tenant cloud environments (which is where most modern software gets built and deployed), Retbleed could allow one tenant to read another tenant's memory. If your CI/CD pipeline runs on shared cloud infrastructure, your build secrets, signing keys, and source code could be at risk.
Firmware updates lag behind. Even after patches are available, getting firmware updates deployed across an organization's hardware fleet takes months. During that window, every build artifact produced on affected hardware should be treated with additional scrutiny.
Affected Systems
The vulnerability affects:
- AMD: Zen 1 and Zen 2 microarchitectures (Ryzen 1000-3000 series, EPYC Rome)
- Intel: 6th through 8th generation Core processors (Skylake, Kaby Lake, Coffee Lake)
- Linux kernel: Versions prior to 5.19 (patched in the 5.19 release)
- Windows: Addressed in July 2022 Patch Tuesday updates
Mitigation Approaches
The Linux kernel team implemented several mitigation strategies:
-
IBRS (Indirect Branch Restricted Speculation): Forces the CPU to respect speculation barriers. This is the most complete fix but carries the highest performance cost.
-
Return thunks (RSB stuffing): Fills the RSB on kernel entry to prevent underflow scenarios. This is less expensive but only addresses the RSB underflow variant.
-
Microcode updates: AMD and Intel released microcode patches that provide hardware-level mitigations, though these still require kernel-side coordination.
For Intel systems, the existing eIBRS (Enhanced IBRS) mitigation was considered sufficient in most configurations. AMD systems required more invasive changes.
The Bigger Picture
Retbleed is part of a pattern that security professionals need to internalize: hardware-level vulnerabilities are not going away. Since the original Spectre and Meltdown disclosures in January 2018, we've seen a steady stream of related attacks — Foreshadow, ZombieLoad, RIDL, Fallout, CacheOut, and now Retbleed.
Each new variant undermines a previous mitigation strategy. The retpoline technique that Retbleed bypasses was itself introduced to fix the original Spectre vulnerability. This arms race between attackers and defenders at the hardware level means that software supply chain security cannot assume the hardware layer is trustworthy.
Organizations need to factor hardware vulnerability management into their supply chain risk assessments. This includes tracking which CPU architectures are used in build environments, ensuring firmware and microcode updates are applied promptly, and considering hardware diversity as a risk mitigation strategy.
Practical Steps
If you're running affected hardware in your build or production environments:
- Update your kernel immediately. Linux 5.19 and later include Retbleed mitigations. Backports are available for LTS kernels.
- Apply microcode updates. Check with your hardware vendor or cloud provider for updated microcode packages.
- Benchmark the performance impact. The mitigation overhead varies significantly by workload. Test your specific CI/CD pipelines and production workloads.
- Audit your cloud provider's response. Major cloud providers (AWS, GCP, Azure) deployed mitigations, but verify the timeline and scope.
- Consider hardware refresh planning. Newer AMD Zen 3+ and Intel Alder Lake processors are not affected by Retbleed.
How Safeguard.sh Helps
Safeguard.sh helps organizations maintain visibility into the full stack of their software supply chain, including the infrastructure layer. By generating comprehensive SBOMs that capture build environment metadata, Safeguard.sh enables teams to identify which artifacts were built on potentially affected hardware. Our policy engine can flag builds produced on unpatched systems, and our continuous monitoring ensures that when new hardware vulnerabilities emerge, you can quickly assess your exposure across your entire software portfolio.