TONTOU Finds a New Timing Gap in Spectre v2 Defences
MIT researchers demonstrated that branch-predictor defences can be re-poisoned in the brief interval between being cleared and being used. This is a local attack, not a drive-by remote compromise.
At Black Hat USA on 6 August, MIT researchers Daniël Trujillo and Mengjia Yan presented a new attack primitive for bypassing recently deployed Spectre v2 mitigations. Their broader research is called TONTOU: Time-of-Neutralisation to Time-of-Use.
The name describes the design problem. A defence can neutralise or isolate a CPU’s branch-prediction state before privileged code runs, but the clean-up and the later use of that state do not happen at precisely the same instant. The instructions between those moments create a very small timing window.
The researchers’ Interrupt Injection technique places carefully timed work inside that window and re-poisons prediction state after the mitigation has acted. The result challenges an important assumption behind some defences: that neutralising state immediately before use is equivalent to keeping it neutral until use.
The demonstration crossed the kernel boundary
The team demonstrated the technique on an AMD Zen 2 system running Linux 6.14 with its default Spectre v2 protections enabled. Conference reporting described a proof of concept that could leak kernel memory, including a demonstration involving password hashes.
This does not mean any website can instantly read passwords from every AMD or Intel computer. The demonstrated scenario started with the ability to execute unprivileged code locally, required precise microarchitectural behaviour and targeted a particular hardware and software combination.
Those constraints reduce immediate mass-exploitation risk, but they do not make the research academic trivia. Shared systems, build workers, research clusters and other environments that run code from multiple trust levels depend heavily on the boundary between an unprivileged process and the kernel.
Product scope still needs careful reading
Spectre-family issues are unusually easy to overgeneralise. A technique may be relevant to a class of processors while a working exploit is demonstrated on only one generation, operating-system version and mitigation configuration.
The USENIX Security 2026 page for the TONTOU paper still described the final paper and abstract as embargoed when this article was prepared. Organisations should therefore distinguish the researchers’ demonstrated configuration from wider claims about every processor that might share the underlying behaviour. Vendor bulletins, operating-system advisories and cloud-provider notices should determine the actual asset scope.
What infrastructure teams should do
- Inventory processor families, kernel versions, hypervisors and microcode across servers and high-risk workstations.
- Keep existing Spectre mitigations enabled. Disabling them for performance reasons removes layers that still block other attack paths.
- Apply supported kernel, hypervisor, firmware and microcode updates after checking vendor guidance and testing operational impact.
- Ask infrastructure and cloud providers whether affected host classes are present and which mitigations they have deployed.
- Prioritise multi-user hosts and systems that execute untrusted customer, student, plugin or build code.
- Reduce unnecessary local-code execution, restrict privileged debugging and performance interfaces, and preserve workload isolation.
- Record accepted residual risk where old hardware cannot receive current firmware or operating-system support.
- Avoid using file or network indicators as the primary detection plan: transient-execution attacks may leave little conventional forensic evidence.
TONTOU’s broader lesson is about security design. A defence that cleans shared state must also protect the interval before that state is consumed. As processors and mitigations become more complex, those tiny intervals deserve the same scrutiny as the security boundary itself.
Official sources and further reading
- Black Hat USA 2026 briefings schedule
- USENIX Security 2026: TONTOU paper page
- Linux kernel documentation: Spectre side channels and mitigations
- Intel: hardware behaviours related to speculative execution
- AMD product security
Hardware and operating-system guidance can change after coordinated disclosure. Confirm the latest vendor position before making configuration changes.
