TONTOU (Time-of-Neutralization to Time-of-Use) is a speculative-execution attack developed by Daniël Trujillo (PhD student) and associate professor Mengjia Yan at MIT CSAIL, presented at Black Hat USA 2026 with a full paper scheduled for USENIX Security 2026 (Baltimore, October 27-29). The name is a deliberate analogue to software TOCTOU races: instead of racing a check against a use, TONTOU races a branch-predictor *neutralization* event (state cleaning performed by a Spectre v2 mitigation) against the *use* of that predictor by a protected branch.

The core primitive is 'interrupt injection': an unprivileged user-mode program schedules high-frequency timer interrupts, invoking syscalls directly (native OS API calls, not a shell/scripting layer) so that one interrupt lands inside the narrow post-neutralization window — on AMD Zen 2 this window is as short as two instructions / six bytes. When the interrupt fires inside that window, the kernel is redirected into the interrupt handler, which the attacker uses to re-poison microarchitectural branch-prediction state (the Return Stack Buffer and Branch History Buffer) before the originally-protected branch executes. The researchers use a four-stage framework — neutralization, redirection, poisoning, use/exploitation — to characterize the race, and combine the primitive with the RSB-training technique from the prior Inception attack (CVE-2023-20569, disclosed by ETH Zurich's COMSEC group, AMD bulletin AMD-SB-7005) to fill the Return Stack Buffer with attacker-chosen targets. An optimization technique evicts target bytes from L1/L2 cache using a sibling hyperthread to slow victim execution and widen the interrupt-landing success window, and the attacker deliberately triggers the race from the `write` syscall specifically, because it leaves two general-purpose registers under attacker control at the moment the interrupt lands; interrupts landed inside the vulnerable window in 5-12% of attempts, falling to roughly 2% when the exploit additionally required those attacker-controlled register values. Reliable end-to-end exploitation required the attacker to first profile the target's exact CPU microarchitecture generation and kernel version — window size and mitigation applicability differ per platform (a two-instruction/six-byte window on Zen 2 versus far lower misprediction rates on Cascade Lake Refresh and Arrow Lake) — so per-platform client-configuration fingerprinting was a precondition for tuning the interrupt-injection timing, not an incidental detail. The full end-to-end AMD Zen 2 demonstration ran on an AMD Ryzen 7 4700G test system (Linux 6.14.0-37-generic, 16GB RAM), where the overall window-landing/misprediction success rate was measured at 0.75% — comparable in kind to the 0.22% (Arrow Lake) and 0.037% (Cascade Lake Refresh) rates recorded on the Intel test platforms, though only the Zen 2 rate translated into a demonstrated end-to-end kernel-memory leak.

This defeats two mitigations that were believed to close the Spectre v2 (Branch Target Injection) attack surface: Intel's enhanced Indirect Branch Restricted Speculation (eIBRS) — whose Branch History Injection countermeasure is enabled via the BHI_DIS_S control — and AMD's Safe RET, the default Linux mitigation for Speculative Return Stack Overflow (SRSO). On an AMD Zen 2 system running a stock Linux 6.14 kernel with all default Spectre v2 mitigations enabled and no inserted kernel modules, the PoC achieved full end-to-end kernel-memory disclosure: a 5.47 bytes/second leak rate at 91.97% accuracy, KASLR bypass in 10 of 10 runs, and recovery of /etc/shadow contents in 5 of 10 attempts, averaging ~18 minutes per automated end-to-end attempt.

Misprediction behavior consistent with the primitive was also observed on other platforms — AMD Zen 1 (behavior demonstrated, not a full kernel-memory leak), Intel Cascade Lake Refresh (0.037% mispredictions) and Arrow Lake (0.22% mispredictions) — though the researchers state a complete end-to-end Intel exploit requires additional software conditions and was not demonstrated; Zen 4 showed no mispredictions in their testing despite being included in AMD's advisory. Zen 3 is listed by AMD as potentially affected but was not independently demonstrated by the researchers.

The researchers privately disclosed TONTOU to AMD, Intel, and Arm on 2026-02-05. A first Linux kernel fix, 'x86/bugs: Make Safe-RET robust against interrupt injection' (commit f5fdd6665ac4d8528ed1c9242cb1cf7a7f5bdb0e, authored by AMD engineers Borislav Petkov and David Kaplan), was merged upstream 2026-06-02; it fixes register state as though Safe-RET had completed and avoids executing the RET instruction after an interrupt return, rather than adding new run-time checks. That fix shipped in stable/LTS kernels 5.10.263, 5.15.214, 6.1.181, 6.6.149, and 6.18.43, plus mainline 7.1.7, on 2026-08-06 (backport commit 7e7f81cf6f5ca3311e526308f55d7c54d3ba71f9). An initial hardening attempt on top of that fix was reverted the same day as incorrect; a corrected, 'hardened' follow-up — adding an LFENCE and a new handle_interrupted_saferet() register-state-adjustment routine so speculative execution cannot leak data when an interrupt lands mid-sequence — shipped the next day, 2026-08-07, in 5.10.264, 5.15.215, 6.1.182, 6.6.150, and 6.12.102 (124 lines across five x86 arch files, authored by Petkov). Mitigation status is exposed to userspace via `/sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow`. The combined fix is tracked as CVE-2026-68480. AMD published security bulletin AMD-SB-7061 ('Safe RET Interrupt Vulnerability') on 2026-08-06, attributing the root cause specifically to the Linux kernel's implementation of Safe RET rather than to AMD silicon, and crediting Daniël Trujillo as the reporting researcher.

Intel's assessment (per Jerry Bryant, Senior Director of Product Assurance) is that the observed behavior relates to Branch History Injection / Indirect Branch Mode Technology Injection (BHI/IMBTI) scenarios already covered by Intel's existing Spectre v2 and BHI/IMBTI guidance, and Intel does not plan additional mitigations; the researchers received a discretionary bug-bounty payment described as 'in the hundreds of dollars.' Arm confirmed awareness, stating that while some Arm CPUs may exhibit aspects of the described behavior, 'this behavior would not give an attacker direct deterministic control over the processor's predicted branch target,' and classifies the leakage as already addressed by existing Spectre-v2/Spectre-BHB guidance with no new mitigation planned. The researchers assess that end-to-end Intel exploitation is plausible by combining the interrupt-injection primitive with existing disclosure gadgets, noting mispredictions are 'a necessary but not sufficient condition for a Spectre attack.'