A new CPU attack skips the branch predictor and still leaks secrets

Classical Spectre v2 attacks work by training the CPU's branch predictor so it guesses the wrong target, then steering the speculative execution that follows. A new attack disclosed this week by researchers at MIT does not train the predictor at all. It injects an interrupt while the processor is unwinding a return, swapping in an attacker-controlled return address after the post-Spectre defenses have already validated the legitimate one. That mechanism delta is why the four mitigations vendors shipped after Spectre v2 (eIBRS, IBTB, STIBP, and IBPB) do not stop it, why the attack works on both Intel and AMD, and why a research proof of concept was able to leak Linux password hashes before AMD published advisory AMD-SB-7061 and the Linux kernel shipped stable patches in 6.18.43, 6.6.149, and 6.1.181.

Speculative execution is the performance trick modern CPUs use to guess ahead on likely branches: the chip starts work on a guess, then either commits the result or throws it away. Spectre v2 attacks turn that trick against the user by poisoning the branch predictor, the small in-chip table that remembers which way branches have gone, so the CPU speculates into attacker-chosen memory. The defenses vendors added after the original 2018 disclosures were built to stop that. Enhanced Indirect Branch Restricted Speculation (eIBRS) constrains which code can influence which branch. Indirect Branch Tracking (IBT) and the Indirect Branch Prediction Barrier (IBPB) block or flush poisoned predictors. Single-Thread Indirect Branch Predictors (STIBP) prevent one thread from poisoning another.

TONTOU sidesteps all four. Instead of poisoning the predictor, it waits for the CPU to push a return address onto the return stack buffer, the small hardware stack that records where ret should go, then injects an interrupt at the exact moment the chip is unwinding that return. The interrupt handler runs with the legitimate return already validated; the speculative window after the interrupt lets the attacker observe memory it should not see, including kernel data. The Safe RET return-path handling that the v2 mitigations were not designed to police becomes the side channel. That is why AMD's advisory AMD-SB-7061 calls out the Safe RET interrupt handling rather than the branch predictor itself.

The proof of concept against Linux is the part that turns a research paper into a news story. BleepingComputer's writeup and The Hacker News describe a working attack that recovered password hashes from a Linux process, the kind of output an attacker could turn into offline cracking. The hashes came from kernel memory, not from a misbehaving user-space program. That is the same shape of leak that made the original Spectre disclosures a multi-year industry problem, only the entry point is new.

The paper comes from Mengjia Yan's group at MIT CSAIL and is on the USENIX Security 2026 program, with a PDF on the authors' page and a CSAIL news release. The Register's coverage ran the same day the kernel patches landed.

AMD published AMD-SB-7061, titled "Safe RET Interrupt Vulnerability," alongside the coordinated disclosure. The Linux kernel shipped mitigations in the 6.18.43, 6.6.149, and 6.1.181 stable releases, covering the long-term, stable, and legacy trees that run the bulk of production servers. Intel's advisory and microcode path are typically slower, but the Safe RET surface is on both vendors' chips because the return stack buffer is a feature both implement for the same reason. The Linux patches are the load-bearing fix for the working proof of concept; the microcode updates will follow.

Speculative-execution flaws have been disclosed and patched since 2018, and TONTOU is a continuation of that arc, not a rupture. The defenses that stop branch-predictor training do not stop interrupt injection on the return path, and the academic disclosure found the gap before an attacker did. That is the system working as designed: vendors publish advisories, kernel maintainers ship stable patches, and the attack surface gets one more entry mapped.

The watch item for the next two weeks is the Intel side. AMD has a published advisory and a vendor scoreboard; Intel's microcode guidance and a clean cross-vendor coordinated disclosure statement are still outstanding. The proof of concept runs on a stock Linux kernel, so distributions that backport stable patches, which is most of them, will close the working attack first. The deeper question, whether the return path needs a more invasive architectural change rather than another per-vendor mitigation, is the one the USENIX paper is asking, and it is the one the next round of disclosures will test.