Researchers Sneak Past Spectre v2 by Slipping Between the Kernel's Own Defenses
MIT CSAIL's 'Interrupt Injection' technique re-poisons the branch predictor in the tiny window after the CPU cleans it and before Linux uses it.

Key points
- MIT CSAIL researchers Daniël Trujillo and Mengjia Yan disclosed a new attack called Interrupt Injection that bypasses Spectre v2 defenses.
- The technique was demonstrated on an AMD Zen 2 processor running Linux 6.14 with every default Spectre v2 mitigation switched on.
- An attacker times a hardware interrupt to land in the gap between the CPU clearing its branch predictor and the kernel using it.
- No unusual privileges are needed: an ordinary, unprivileged Linux program can pull it off.
- The finding revives a class of processor-level attacks that chip makers and Linux maintainers have been patching against since 2018.
A new academic attack shows that even a fully patched Linux machine can still be tricked into leaking secrets from its own kernel, the core program that runs the operating system.
Daniël Trujillo and Mengjia Yan at MIT's Computer Science and Artificial Intelligence Laboratory named it Interrupt Injection, and The Hacker News reported it first. It's a fresh angle on Spectre v2, a family of processor flaws from 2018 that let a program guess at data it has no right to see.
What is Spectre v2, in plain terms?
Modern processors try to work faster by predicting what they'll be asked to do next. That prediction engine is called the branch predictor. Spectre v2 attacks corrupt those predictions so the chip briefly runs attacker-chosen code, leaving traces in memory that expose secrets like passwords or encryption keys.
Chip makers and Linux developers have spent seven years bolting on defenses. One tells the processor to sanitize its branch predictor, wiping any corrupted predictions, before the kernel begins running sensitive code.
How does Interrupt Injection get around that?
By squeezing into the gap. There's a sliver of time between the moment the CPU cleans the predictor and the moment the kernel actually uses it. An unprivileged program, meaning any normal app with no special permissions, can time a hardware interrupt (a signal from a device like a network card that briefly grabs the processor's attention) to land inside that sliver.
When the interrupt fires, it re-corrupts the branch predictor after the defense has already run. The kernel walks straight into the trap.
Which systems are affected?
Trujillo and Yan demonstrated it on an AMD Zen 2 machine running Linux 6.14, every default mitigation on. They say the underlying idea isn't specific to one vendor, with both Intel and AMD chips considered in scope.
| Detail | Value |
|---|---|
| Attack name | Interrupt Injection |
| Researchers | Daniël Trujillo, Mengjia Yan (MIT CSAIL) |
| Confirmed CPU | AMD Zen 2 |
| Confirmed OS | Linux 6.14 |
| Privileges needed | None (unprivileged local program) |
| Bypasses | Default Spectre v2 mitigations |
Should ordinary people be worried?
Not in the panic-today sense. This is a local attack: the person running it needs to already be executing code on your machine. It can't be fired from a random website at your laptop.
The real risk sits with cloud providers and shared servers, where many customers' programs live on the same physical processor. That's exactly the setting Spectre-class attacks were built to worry about. Our earlier coverage of Linux privilege-escalation flaws shows how quickly local-only bugs move from theory to working exploit once details are public.
For home users, the practical advice is dull and familiar: install operating system updates when your vendor ships them.
What comes next?
Chip vendors and Linux kernel maintainers now have to close a timing gap they may not have known was exploitable. History suggests a mix of microcode updates from the chip makers and kernel changes to prevent interrupts landing in that vulnerable window.
Interrupt Injection isn't a smash-and-grab bug. It's a reminder that processor defenses are only as strong as their worst-timed moment, and that seven years of patches haven't sealed every crack. What to watch: whether Intel's own hardware reproduces the result, and how long the gap between disclosure and a kernel fix turns out to be.



