# The Fix Has a Gap: MIT Researchers Crack Spectre v2 Defenses Using a Hardware Interrupt Race
The defenses work. The timing doesn't. That's the core finding from MIT CSAIL researchers Daniël Trujillo and Mengjia Yan, who demonstrated last week that an unprivileged Linux process can bypass every default Spectre v2 mitigation on AMD Zen 2 hardware by doing something deceptively simple: firing a hardware interrupt at exactly the right moment.
They named the technique INTERRUPT INJECTION. And it matters because the systems it defeats aren't unpatched legacy boxes — they're running Linux 6.14 with the full stack of Spectre v2 defenses enabled.
---
## Why Spectre v2 Mitigations Exist, and What They Actually Do
When Spectre v2 (Branch Target Injection) dropped in January 2018 alongside Meltdown, it exposed a fundamental problem: CPUs train their branch predictors to go fast, and that training can be poisoned by an attacker to redirect speculative execution into kernel memory, leaking secrets across privilege boundaries.
The industry response was architecturally messy. Intel shipped Indirect Branch Restricted Speculation (IBRS). AMD and Intel both leaned on Indirect Branch Predictor Barrier (IBPB). Linux developed retpoline sequences. The underlying idea in all of them: sanitize the branch predictor state before a privilege transition, so the attacker's poisoned predictions can't influence what the kernel speculatively executes.
On paper, the logic holds. Clean the predictor, execute the kernel code, no cross-privilege contamination. The mitigation is sound *in principle*.
The problem is in the gap between "clean" and "use."
---
## The Race Condition Built Into the Defense
Modern operating systems aren't sequential — they're interrupt-driven. Hardware interrupts arrive asynchronously: a NIC receives a packet, a timer fires, a disk operation completes. The kernel's interrupt handler runs wherever the CPU happens to be in its execution stream.
Here's what INTERRUPT INJECTION exploits: the processor sanitizes the branch predictor, but before the kernel can act on that clean state, a hardware interrupt fires. That interrupt handler runs in kernel context. An attacker who can influence the timing of that interrupt — and on Linux, unprivileged programs have enough scheduling visibility to do exactly that — can re-poison the branch predictor *after* sanitization but *before* the critical kernel code executes.
The mitigation ran. The mitigation passed. And then the attacker's poisoned prediction was back in play.
This is a time-of-check-time-of-use (TOCTOU) flaw, but embedded in CPU microarchitecture rather than a file system. The "check" is the sanitization. The "use" is the kernel's subsequent speculative execution. The interrupt is the gap between them.
Trujillo and Yan demonstrated this on AMD Zen 2 under Linux 6.14 — current kernel, current hardware, default mitigations, fully exposed.
---
## What an Attacker Can Actually Steal
Spectre-class vulnerabilities are side-channel attacks, not direct memory reads. The exploitation flow requires:
1. Mistrain the branch predictor to speculatively execute a gadget inside the kernel that reads sensitive memory
2. Trigger speculative execution of that gadget before the CPU detects the misprediction and rolls back
3. Encode the secret into the cache state before rollback
4. Flush + Reload the cache to recover the secret
INTERRUPT INJECTION resets step 1 after sanitization, making steps 2–4 viable again. Practically speaking, the attack can leak kernel memory contents — including credentials, cryptographic keys, and memory mappings — from an unprivileged user process on the same machine.
Cloud tenants sharing AMD Zen 2 hardware with other tenants are the obvious highest-risk scenario. Same-machine privilege boundaries are exactly what Spectre v2 was supposed to protect.
---
## Which Hardware Is in the Crosshairs
The researchers confirmed Zen 2 (Ryzen 3000, EPYC Rome) under Linux 6.14. The architectural conditions — interrupt timing windows, branch predictor behavior, kernel sanitization implementation — are not unique to AMD. Intel processors with eIBRS and retpoline configurations may have analogous exposure, though that surface hasn't been fully mapped yet in the published work.
Zen 2 specifically matters because EPYC Rome is still powering a substantial slice of cloud infrastructure. AWS, Google Cloud, and Azure all offered Zen 2 instances; many enterprises bought them for on-prem VMware and KVM workloads. These aren't niche boxes.
---
## What Defenders Can Actually Do Right Now
The honest answer is: not much, immediately. This requires either a microcode fix from AMD (which would close the interrupt window at the hardware level) or a more aggressive software mitigation that makes sanitization and subsequent execution atomic with respect to interrupts — which means disabling interrupt delivery for that window, with real performance consequences.
Defenders running AMD Zen 2 in multi-tenant environments should:
spectre_v2=retpoline,ibpb with forced IBPB on context switches) at a performance cost — this shrinks the window even if it doesn't close it completely---
## HackWire Analysis
INTERRUPT INJECTION is the latest proof that the Spectre story is a long-tail problem, not a one-time patch cycle. Consider the arc: Spectre/Meltdown (2018) forced IBRS and retpoline. Retbleed (2022) showed that return-address-based speculation could bypass retpoline on Intel and AMD. INCEPTION (2023) found Training Source Mismatch conditions on AMD's entire Zen line. Indirector (2024) showed precision attacks against the Indirect Branch Predictor Barrier itself on Intel. Now INTERRUPT INJECTION shows that the timing model underlying sanitization is itself flawed.
The pattern is consistent and uncomfortable: the defenses are logically correct but physically incomplete. Each mitigation closes a conceptual gap while leaving an implementation gap. Researchers are systematically finding those implementation gaps faster than microcode and kernel patches can close them.
What other coverage is underplaying: this isn't really an AMD-specific story. The interrupt-based timing window is a consequence of how interrupts interact with any sanitization sequence. Intel's eIBRS implementation almost certainly deserves the same scrutiny. Trujillo and Yan focused on Zen 2, but the methodology is generalizable.
The deeper problem for defenders is that "enable all mitigations and patch promptly" — which is correct advice — is no longer sufficient assurance. There is now a class of attacks targeting the *transitions between* mitigation states rather than the mitigations themselves. That's a harder threat model. It means even diligent, patched systems carry residual speculative execution risk until hardware vendors build interrupt-atomicity guarantees into the silicon itself.
AMD and Intel need to treat this as a design requirement for the next microarchitecture generation, not just a microcode hotfix for Zen 2.
— HackWire Editorial
---
## Related Coverage