Researchers at MIT have reopened one of the most uncomfortable chapters in modern system security. Dubbed TONTOU — short for Time-of-Neutralization to Time-of-Use — the technique exploits a tiny window to re-poison the CPU's branch predictor after a Spectre v2 mitigation neutralizes the threat, but before the kernel uses the branch. The result is unsettling: on an AMD Zen 2 host running Linux with the latest protections, the researchers read kernel memory at about 5.47 bytes per second with 91.97% accuracy, locating /etc/shadow, which holds password hashes, in five of ten attempts.
To understand the impact, it helps to recall what Spectre v2, also called Branch Target Injection (BTI), is. Modern processors execute instructions speculatively, guessing the targets of indirect branches through a branch target buffer (BTB). When a prediction fails, the architectural state is discarded, but side effects on the cache linger. Those timing footprints let a local attacker reconstruct secret data that should never have been read.
Known defenses, such as Intel's eIBRS and AMD's Safe RET, exist to neutralize the BTB: they clear or constrain speculative targets at the transition from user space to the kernel. This is where TONTOU enters. The defense neutralizes the predictor at one instant, but the kernel only consumes the branch a few cycles later. In that interval — on Zen 2, just two instructions, six bytes — an attacker can inject a timer interrupt and re-poison the BTB before use.
The attack unfolds in clear stages: neutralization, redirection, poisoning, and use. The victim is steered into redirecting speculative flow toward a gadget that leaks data through a side channel. As the authors show in their USENIX Security 2026 paper, the technique sidesteps the design assumptions of both Safe RET and eIBRS, not just one.
TONTOU is not isolated; it is another link in a long chain. Since Spectre and Meltdown in 2018, the industry has dealt with Retbleed, Inception, and variants that recycle the same principle: speculation is too efficient to abandon, but every software mitigation creates windows that later attacks exploit.
Why do mitigations keep being bypassed? Because the problem is structural. Truly fixing the microprocessor would mean redesigning branch prediction, a performance cost vendors are reluctant to pay. The answer falls to software barriers, band-aids that cover known flows, but not the space of every possible flow between neutralization and use.
For Linux systems and cloud environments, the severity is significant. The exploit requires unprivileged local access, but in shared infrastructure — containers, VMs, multiuser servers — that is exactly the risk scenario. Leaking password hashes and encryption keys from kernel memory undermines the isolation model. CVE-2026-68480 has already received fixes in kernels 6.18.43, 6.6.149, and 6.1.181, and AMD acknowledged impact across Zen 1 through Zen 4.
The practical mitigation, for now, is the old recipe: keep the kernel updated, minimize the local exposure surface, and where risk is high, consider stricter isolation between workloads. The low exfiltration rate still limits real-time attacks, but the accuracy and the ability to locate specific files make the threat real.
The lingering question is provocative: if every Spectre v2 defense created a new window, are we doomed to an endless cat-and-mouse game, or will performance one day give way and the industry finally redesign branch prediction at the architecture level?
Sources: BleepingComputer, The Hacker News, USENIX Security 2026 (MIT, Privacy Guides, LinuxCompatible
✓ Independent sources cross-checked and verified before publishing
