TONTOU ReFocuses on Spectre: Impacts Intel and AMD Mitigations

Eight years after the appearance of Spectre, researchers at MIT CSAIL have demonstrated that certain defenses against speculative execution attacks can become exposed again if an interruption occurs precisely within the tiny window between predictor cleanup and its subsequent use. The work, called TONTOU, affects scenarios studied on Intel and AMD processors and has prompted AMD to publish a mitigation for Linux related to Safe RET.

The key points of TONTOU in 20 seconds

• TONTOU exploits time windows that appear between predictor neutralization and its next use.
• The researchers use a technique called Interrupt Injection to introduce activity within that interval.
• Tests include Intel Cascade Lake Refresh and Arrow Lake processors, as well as AMD Zen 2 and Zen 4.
• On AMD Zen 2, they developed an exploit capable of extracting kernel information.
• AMD attributes the observed issue to the Linux implementation of Safe RET and recommends updating the system.

The research does not reveal another classic variant based simply on training the predictor from an attacker process. Its contribution is showing that even a mitigation that seemingly clears the speculative state correctly can fail if there is an interval between when that state is neutralized and when it is reused.

The concept gives the work its name: Time-of-Neutralization to Time-of-Use, TONTOU.

The study is authored by Daniël Trujillo and Mengjia Yan from MIT CSAIL and is part of the USENIX Security 2026 program.

A nanosecond interruption can re-contaminate the predictor

Modern processors use speculative execution to anticipate the actual program flow. Instead of waiting to know the result of each jump, they try to predict which path will be followed and start executing instructions ahead of time.

When the prediction is incorrect, these operations are architecturally discarded. The problem Spectre exposed in 2018 is that certain microarchitectural effects can remain and be used as a side channel to infer information.

Subsequent mitigations attempt to prevent an attacker from controlling the state used by these predictors.

TONTOU indicates a different weakness.

After cleaning or isolating the predictor, there is inevitably some code before the CPU reuses that information. If an interruption occurs right there, the handler itself can modify the microarchitectural state again.

The researchers refer to Interrupt Injection as the technique used to achieve this.

A local program can use timers to provoke interruptions and gradually adjust its execution timing to coincide with those windows.

The required precision can be extreme. In AMD’s Safe RET mitigation, the researchers describe a window of just two instructions.

Yet, they managed to reach it.

Intel also showed incorrect predictions despite existing defenses

The study evaluated four platforms:

Intel researchers were able to cause incorrect predictions in protected situations involving mechanisms related to cleaning the jump history and BHI_DIS_S.

The latter is a control designed to limit the influence of jump history on predictions made at privileged levels. Intel documents BHI_DIS_S as part of its mitigations for Branch History Injection (BHI) and also provides the IBHF, Indirect Branch History Fence instruction, meant to prevent previous history from influencing certain subsequent predictions.

The behavior observed by TONTOU doesn’t automatically mean all these protections are useless on any Intel processor.

In fact, one conclusion of the study is that the effectiveness of a single defense can vary among microarchitectures.

Intel offers specific recommendations depending on the processor generation and capabilities, including BHI_DIS_S, software sequences to clear the Branch History Buffer (BHB), IBPB, and other measures depending on the scenario.

Therefore, the practical impact of TONTOU on Intel needs to be assessed per platform and configuration, not just brand.

On AMD Zen 2, they moved from theory to reading kernel memory

The most worrying demonstration of the study was on AMD Zen 2.

Safe RET is the software mitigation used by Linux against Speculative Return Stack Overflow (SRSO) in certain AMD processors. The kernel documentation lists safe-ret as one mitigation option, alongside microcode or IBPB alternatives.

TONTOU manages to introduce the interruption between the cleanup performed by Safe RET and the speculative return that this cleanup aims to protect against.

The researchers then built a complete exploitation chain on Linux.

According to the results, they first managed to break KASLR (Kernel Address Space Layout Randomization) in all ten tests, averaging about nine minutes.

KASLR randomizes the kernel’s location in memory to make it harder for an attacker to determine addresses needed for exploitation.

Once this protection was bypassed, TONTOU allowed extracting arbitrary kernel memory at approximately 5.47 bytes per second, with an accuracy close to 91.97%.

While this isn’t a fast rate, a side channel doesn’t necessarily need to transfer megabytes per second to be useful.

The researchers used this ability to try to locate /etc/shadow, the file in Linux systems that stores password hashes.

They succeeded in five out of ten attempts, with an average duration of about 18 minutes.

This makes TONTOU more than just a proof of concept that incorrect predictions are still possible.

It’s not a remote attack, but it’s especially relevant in shared servers

Exploiting the scenario described requires running unprivileged local code on the affected system.

Therefore, TONTOU can’t directly compromise a vulnerable machine via internet traffic alone.

This significantly reduces the risk for a typical PC running only trusted software.

However, the scenario changes in multi-user infrastructures, shared hosting servers, development platforms, and certain cloud environments.

In such cases, it’s common for code from different users to share the same physical hardware. Microarchitectural attacks are especially relevant here because they attempt to bypass protections that, from the OS or hypervisor perspective, should be maintained.

USENIX states in its 2026 program that microarchitectural attacks remain a specific concern in public clouds due to the risk of data leakage between tenants sharing physical infrastructure.

That said, TONTOU does not automatically allow escaping from any VM or compromizing any cloud provider. Exploitation depends on processor, kernel, mitigation availability, and attacker’s ability to run code under the necessary conditions.

AMD confirms Zen 1 to Zen 4 within the scope of Safe RET

AMD published its response as AMD-SB-7061, Safe RET Interrupt Vulnerability.

The manufacturer explains that an external researcher reported that a carefully synchronized interruption could weaken Safe RET, AMD’s default Linux mitigation against SRSO.

AMD notes that this behavior was demonstrated on Zen 1 and Zen 2 and that researchers believe Zen 3 and Zen 4 could also be affected by the same principle, although the specific exploit was not demonstrated on those generations.

AMD’s assessment is significant because it mainly attributes the problem to the Linux implementation of Safe RET, rather than to a hardware fault requiring processor replacements.

The company and kernel maintainers are working on software mitigation, so the practical advice for sysadmins is much simpler than the attack: keep the Linux kernel updated and apply distribution updates.

Will Spectre patches continue to reduce performance?

This is probably the most interesting question from an infrastructure management perspective.

Initial patches against Spectre and Meltdown showed that protecting certain speculative transitions could introduce measurable costs, especially in workloads with many system calls, virtualization, and I/O operations.

TONTOU revisits that trade-off.

A seemingly straightforward solution would be to re-clean the predictor after each interruption.

The researchers consider this approach potentially useful on some AMD processors. However, they warn that behavior may not directly translate to Intel CPUs.

Another possibility involves using stronger mechanisms such as IBPB (Indirect Branch Prediction Barrier).

Linux already supports IBPB as part of the mitigation for SRSO on AMD systems:

spec_rstack_overflow=ibpb

It also supports:

spec_rstack_overflow=ibpb-vmexit

which is specifically aimed at applying IBPB during VMEXIT in cloud scenarios.

The challenge is that stronger barriers may have a greater impact on performance.

Blocking interruptions during all sensitive windows is another conceptual solution, but the researchers consider it could be too costly.

For now, there’s not enough data to say that TONTOU will cause widespread performance degradation comparable to some mitigations introduced after 2018.

Final mitigation depends on each manufacturer, microarchitecture, and operating system.

Spectre remains a family of issues, not a closed vulnerability

TONTOU also leaves a broader lesson.

Mitigations against speculative execution are often analyzed assuming a fairly clean sequence:

contaminated state
      ↓
mitigation
      ↓
clean state
      ↓
safe use

The research shows that the actual system can look more like this:

contaminated state
      ↓
mitigation
      ↓
clean state
      ↓
INTERRUPTION
      ↓
new microarchitectural state
      ↓
predictor use

The issue is not necessarily that the cleanup operation fails.

It may be in what happens after the cleanup but before using the protected resource.

These TOCTOU (Time of Check to Time of Use) windows have been known in software security for decades. TONTOU applies a similar concept at a microarchitectural level, which is much harder to observe.

That’s why Spectre continues to drive research eight years later.

Manufacturers have significantly hardened their processors, and operating systems incorporate multiple layers of protection. Nevertheless, speculative execution remains an essential part of modern CPU performance. The ongoing challenge is to harness it without letting internal states—used to speed up the processor—become a source of information leakage.

Frequently Asked Questions

What is TONTOU?

TONTOU is a new class of attack researched by MIT CSAIL that exploits the interval between the neutralization of certain speculative predictor states and their subsequent reuse.

What is Interrupt Injection?

It is the technique used by researchers to provoke an interruption at a very specific moment and then modify the microarchitectural state again after a mitigation has cleared it.

Which processors were tested?

The study used AMD Ryzen 7 4700G, AMD EPYC 9124, Intel Xeon Gold 5220R, and Intel Core Ultra 9 285H. The full memory leakage exploit was developed on AMD Zen 2.

What should system administrators do?

On affected AMD systems using Safe RET, AMD recommends applying system updates that include the mitigation. For servers and cloud environments, review the protections for Spectre/SRSO provided by the kernel, distribution, and manufacturer.

Sources:

• MIT CSAIL / Daniël Trujillo and Mengjia Yan, research TONTOU: On the Exploitability of Time-of-Neutralization to Time-of-Use Windows.
• USENIX Security 2026, technical program and TONTOU presentation.
• AMD, AMD-SB-7061: Safe RET Interrupt Vulnerability, 06/08/2026.
• Linux Kernel Documentation, mitigation for Speculative Return Stack Overflow (static.lwn.net).
• Intel, Branch History Injection, BHI_DIS_S, and IBHF documentation.