TONTOU: interrupt injection slips through a Spectre v2 mitigation window

Spectre v2 defences assume that the processor neutralises branch-prediction state before entering code that must not be redirected speculatively. MIT researchers have shown that a short sequence of instructions remains between neutralisation and use. The TONTOU class — Time-of-Neutralization to Time-of-Use — targets that gap.

In the Interrupt Injection variant, an attacker causes an interrupt to be handled at a carefully selected moment. Code that runs after predictor clearing but before the protected branch can prepare the state again. The demonstration bypassed deployed Spectre v2 mitigations and recovered information from Linux kernel memory.

Why this is not an ordinary TOCTOU

A conventional time-of-check to time-of-use bug changes an object between validation and use. TONTOU concerns microarchitectural state. A defence clears or isolates prediction structures but cannot make every event between that operation and the next indirect branch disappear. An asynchronous interrupt becomes controlled work inserted into that window.

The TONTOU paper at USENIX Security 2026 describes how the researchers measure these windows and determine whether they can be exploited. The important observation is that security depends not only on IBRS, retpoline or a clearing instruction, but also on what may execute before the protected resource is first used.

The side channel still requires local code execution, careful synchronisation and repeated measurements. It is not a one-packet remote kernel dump. Multi-tenant clouds, browsers, CI platforms and hosts that execute untrusted code are nevertheless environments where those prerequisites matter.

What the researchers demonstrated

The team retrained prediction state “in the shadow” of a mitigation and leaked information while Spectre v2 controls were active. Password hashes present in kernel memory provided a clear proof. This confirms a confidentiality impact, but it does not mean any process can immediately recover every secret.

Actual risk depends on processor microarchitecture, kernel build, mitigation configuration, control over interrupt timing and the available speculative gadget. Inventory must connect CPU model, microcode, kernel and workload type.

Defence plan

1. Track both processor-vendor and Linux-distribution guidance, and deploy microcode and kernel updates as one change set.
2. Reduce untrusted execution on hosts that share hardware with sensitive workloads; tenant separation does not create separate microarchitecture.
3. Restrict unnecessary high-resolution timers and performance counters for unprivileged users.
4. Place high-value trust domains on separate physical hosts where the risk justifies it.
5. Verify active mitigations from the running system rather than relying on a base-image declaration.
6. Include speculative attacks in threat models for sandboxes, CI runners, serverless functions and customer-code execution services.
7. Do not expect conventional network IOCs; local execution exposure, unusual sampling and shared-core placement matter more.

Patch validation must measure CPU behaviour

Package inventory is insufficient for microarchitectural flaws. Effective protection is a combination of processor model, microcode, kernel, hypervisor and boot flags. The same system image may behave differently after a VM migrates to a host with another CPU generation. Platform teams should record these parameters for every node and associate them with workload classes.

Regression testing should run on owned hardware with controlled measurement code, never by reproducing an attack against third-party systems. Tests need to establish whether interrupts and context switches restore predictor state in a form accessible to another trust domain. Performance counters, unusual pre-emption frequency and correlation with cache tests may assist investigation, but rarely form a definitive indicator. Patching and separation of differently trusted tenants therefore remain the primary controls.

Facts versus Breachroad analysis

The research confirms a new primitive and controlled demonstrations on specified configurations. It does not establish mass exploitation or exposure of every processor. Physical separation for the most sensitive workloads is a defensive conclusion based on the difficulty of detecting side channels.

Training for administrators and cloud teams should connect patching with hardware-sharing models. A cloud security assessment can verify placement, hosts executing untrusted code and evidence that mitigations are active.