The discovery of a new speculative-execution attack known as TONTOU demonstrates that modern Spectre v2 mitigations can fail during the extremely small interval between cleaning the processor’s branch-prediction state and actually using that state. Researchers Daniël Trujillo and Mengjia Yan from MIT’s Computer Science and Artificial Intelligence Laboratory showed that an unprivileged program can deliberately trigger hardware interrupts at carefully selected moments, redirect kernel execution and re-poison branch predictors after existing protections have already attempted to neutralize them. Their proof of concept successfully leaked arbitrary Linux kernel memory from an AMD Zen 2 system, including password hashes stored in `/etc/shadow`. 

TONTOU stands for Time-of-Neutralization to Time-of-Use and is conceptually similar to a Time-of-Check to Time-of-Use software vulnerability. In an ordinary TOCTOU flaw, a system checks a condition and later performs an action based on that result, while an attacker modifies the underlying state during the interval. TONTOU applies the same principle to processor microarchitecture. A mitigation clears or isolates branch-predictor state, but there remains a brief interval before a protected indirect branch or return instruction consumes that state. The attack exploits this interval to introduce attacker-influenced predictions after the protection has run but before the processor relies on the supposedly safe predictor state.

Spectre v2 attacks manipulate indirect branch prediction so that the processor speculatively executes instructions at an attacker-influenced location. Although the CPU eventually recognizes the incorrect prediction and discards the architectural result, the speculative execution can leave measurable traces in caches and other microarchitectural structures. An attacker can analyse those traces to infer information from memory that should have remained inaccessible, including passwords, encryption keys and kernel data.

Processor and operating-system vendors have spent years introducing mitigations intended to prevent user-controlled branch-predictor state from influencing privileged kernel execution. Intel systems use protections such as Enhanced Indirect Branch Restricted Speculation, branch-history clearing and hardware mechanisms designed to isolate prediction state between security domains. Linux systems running on affected AMD processors use Safe RET to protect return instructions against attacks targeting the Return Stack Buffer. These protections differ technically, but many share the same assumption: once predictor state has been neutralized, an attacker cannot influence it before the protected branch uses it.

TONTOU shows that this assumption is incomplete because interrupts can occur inside the post-neutralization window. Interrupts are fundamental to operating-system behaviour and can redirect execution when a timer expires, a network packet arrives or a hardware device requires attention. Kernel developers have generally considered interrupt handlers trusted code that might introduce performance noise but would not provide an unprivileged attacker with a controlled mechanism for poisoning branch predictors.

The researchers demonstrated that ordinary user programs can schedule high-frequency timer interrupts and increase the probability that one will occur during the small interval between neutralization and use. When the interrupt fires, the processor temporarily redirects execution from the protected kernel path into an interrupt handler. The attacker then uses the handler’s branch activity, sometimes combined with previously known speculative-execution techniques, to alter the relevant predictor state. When the handler finishes and execution returns to the original kernel path, the protected branch may consume the newly poisoned state and speculatively jump to a disclosure gadget.

Achieving this reliably required overcoming several timing and prediction challenges. Some post-neutralization windows contain only a few instructions, leaving very little time for an interrupt to arrive. The researchers improved their chances by triggering interrupts frequently and evicting selected instructions from the processor cache, which slowed execution through the target window. Repeating the process and analysing multiple samples allowed them to extract data despite individual attempts producing noisy or incomplete results.

On AMD Zen 2, the attack combined interrupt injection with Inception, an earlier speculative-execution technique capable of poisoning the Return Stack Buffer through transient execution. AMD’s Safe RET mitigation normally places a benign return target into the RSB immediately before each protected return instruction, preventing older attacker-controlled entries from being used. TONTOU introduces an interrupt after this protective step and uses the interrupt handler as an opportunity to poison the RSB again before the return instruction executes.

This effectively revives an attack that Safe RET was specifically designed to prevent. The mitigation correctly places a safe prediction into the processor, but its protection depends on nothing altering that prediction during the following instructions. The interrupt provides the attacker with exactly that opportunity, demonstrating that security mechanisms built around momentary sanitization must also protect the period in which the sanitized state remains exposed.

The researchers implemented a complete kernel-memory disclosure attack on an AMD Ryzen 7 4700G system running Linux kernel 6.14.0-37-generic with 16GB of memory and current Spectre v2 mitigations enabled. The exploit leaked data at approximately 5.47 bytes per second with an accuracy of 91.97%. Although this speed is slow compared with ordinary memory access, speculative-execution attacks do not need to transfer large files to be useful. Password hashes, cryptographic secrets, access tokens and pointers can be valuable even when only a small number of bytes are recovered.

The proof of concept successfully located and extracted `/etc/shadow`, the protected Linux file containing password hashes and account information. Across ten test runs, the attack found the file in five cases and required an average of around 18 minutes for each successful attempt. This is not the reliability or speed of a conventional privilege-escalation exploit, but it provides a practical demonstration that current mitigations can be bypassed under realistic system conditions.

The attack does not provide remote compromise by itself. The researchers assume that the attacker can already execute arbitrary but unprivileged code on the target Linux machine. This could occur through a compromised user account, malicious local application, container workload, shared hosting account or another vulnerability that provides limited code execution without kernel access. TONTOU then provides a method for reading privileged memory that should remain isolated from the attacker.

This threat model makes the issue particularly relevant to multi-user servers, cloud systems, hosting platforms and environments where mutually untrusted workloads share the same physical processor. A personal desktop on which only trusted software runs presents a lower practical risk, while a server allowing customers, developers or containers to execute arbitrary code offers a more plausible attack environment. Speculative-execution weaknesses become most valuable when one attacker-controlled process shares hardware resources with sensitive kernel or application data.

The demonstration on AMD Zen 2 does not mean that only one processor generation is relevant. The researchers observed interrupt-based speculative misprediction behaviour across tested AMD and Intel processors, including AMD Zen 2 and Zen 4 systems and Intel Cascade Lake Refresh and Arrow Lake processors. The precise exploitation technique differed because the vendors use different predictor designs and mitigations. The complete arbitrary kernel-memory leak was demonstrated on AMD Zen 2, while attacks against Intel required additional software conditions and were therefore more complex.

On Intel systems, the researchers showed that an interrupt handler could manipulate Branch History Buffer state after existing protections had attempted to clear or isolate it. This could produce mispredictions of indirect jumps and calls despite mitigations such as software branch-history clearing and BHI_DIS_S. Intel acknowledged the underlying behaviour but stated that practical exploitation depends on several factors and considered the issue covered by its existing guidance for speculative-execution attacks.

AMD published an advisory describing the issue as a potential weakness affecting the Linux implementation of Safe RET. AMD listed Zen 1 through Zen 4 processors as affected, although the researchers directly demonstrated the behaviour on Zen 1 and Zen 2 and indicated that later generations may also be susceptible. AMD has said it plans to address the problem through a Linux kernel change rather than a processor microcode update.

The difference in vendor assessments illustrates the difficulty of assigning simple vulnerability boundaries to speculative-execution research. The underlying processor may permit predictor manipulation, while the practical attack depends on operating-system code, enabled mitigations, interrupt behaviour, available disclosure gadgets and the attacker’s ability to run local code. Hardware and software jointly create the vulnerable condition, making responsibility and remediation less straightforward than patching a conventional memory-corruption bug.

The research also shows why Spectre-class vulnerabilities remain difficult to eliminate permanently. Modern processors depend heavily on branch prediction, speculative execution and caching to achieve acceptable performance. These optimizations intentionally allow the CPU to perform work before all security and control-flow decisions are architecturally resolved. Mitigations attempt to constrain which speculative paths can influence protected execution, but researchers continue to find new microarchitectural states and timing windows that were not fully considered.

Neutralization-based protections are especially fragile because they create security only at a particular point in time. Clearing the predictor on kernel entry, before an indirect branch or immediately before a return can remove existing attacker state, but the mitigation must also guarantee that no attacker-controlled activity modifies the predictor afterward. TONTOU demonstrates that ordinary operating-system interrupts violate that assumption.

Preventing interrupts during the post-neutralization window appears conceptually simple but creates difficult performance and engineering problems. For a short in-place mitigation such as Safe RET, Linux could temporarily mask interrupts between predictor cleaning and the protected return. However, return instructions occur extremely frequently, meaning repeatedly disabling and enabling interrupts could introduce measurable overhead and increase interrupt latency. Some non-maskable interrupts may also remain unavoidable.

For entry-based mitigations, blocking interrupts throughout kernel execution would be impractical because the post-neutralization window may last until the kernel eventually reaches a protected branch. Disabling interrupts for such long periods would reduce responsiveness, delay device handling and undermine normal operating-system scheduling. The research therefore exposes a structural weakness without providing one inexpensive universal correction.

Another potential defence is to ensure that interrupt handlers cannot poison predictor entries consumed by protected kernel branches. This may require additional predictor barriers, branch-history clearing or changes to how interrupt entry and return are implemented. Such protections must be applied carefully because interrupt handlers execute constantly on busy systems, and expensive barriers could reduce performance substantially.

Processor vendors may ultimately need hardware mechanisms that allow operating systems to establish a protected prediction domain lasting across interruptions and other asynchronous events. A mitigation that merely clears the current state cannot guarantee safety if the processor allows that state to be recreated before it is used. Future designs may need stronger guarantees about how branch predictors are partitioned, tagged or frozen between security transitions.

Organizations cannot realistically detect TONTOU exploitation through ordinary antivirus signatures. The attack uses legitimate timer APIs, kernel transitions, cache measurements and speculative processor behaviour rather than dropping a recognizable malware file. High-frequency timer activity and unusual performance-counter patterns may provide research-level detection opportunities, but distinguishing an attack from legitimate software and system activity would be difficult.

Hardware performance counters can sometimes reveal elevated branch mispredictions, cache activity or interrupt rates associated with speculative-execution attacks. However, attackers can adjust sampling rates and spread activity over time, while many legitimate workloads produce similar signals. Detection should therefore be considered a secondary control rather than a substitute for vendor fixes and workload isolation.

The immediate defensive response should be to monitor Linux distribution, AMD and Intel advisories and install relevant kernel, microcode and firmware updates when they become available. Organizations should avoid attempting to build their own low-level mitigations unless they have the necessary kernel and processor expertise, as incorrect changes could cause instability without providing meaningful protection.

Administrators should also review where untrusted local code can execute. Shared servers, CI/CD runners, research clusters and multi-tenant development systems deserve particular attention. Reducing the number of users and workloads sharing a physical host decreases opportunities for local speculative-execution attacks. Sensitive administrative workloads should not run on the same systems as untrusted customer code merely because process and container isolation appears sufficient at the software layer.

Containers do not provide separate kernels or processors. A malicious process inside a container may remain limited by namespaces and capabilities, yet it still executes on the host CPU and interacts with the same kernel. Speculative-execution attacks can therefore cross boundaries that appear strong from an ordinary operating-system perspective. Container security should include hardware and kernel isolation considerations rather than assuming that namespaces prevent every form of information leakage.

Cloud providers and operators of virtualized infrastructure should evaluate whether high-risk tenants can share physical cores with sensitive workloads. Core scheduling, dedicated hosts and stronger tenant placement controls may reduce exposure, although speculative attacks can sometimes cross sibling cores or shared processor structures depending on the technique. Customers with unusually sensitive workloads may need hardware isolation rather than relying solely on virtual-machine boundaries.

Password hashes leaked from `/etc/shadow` do not immediately reveal plaintext passwords, but they enable offline cracking attempts. Weak, reused or short passwords may be recovered using dictionaries and high-performance password-cracking hardware. Organizations should continue using strong password-hashing schemes such as yescrypt or properly configured SHA-512-based hashing and should encourage long, unique passwords. Strong hashing does not prevent the memory leak, but it reduces the value of the stolen data.

The same attack concept could potentially target secrets more immediately useful than password hashes. Kernel memory may contain cryptographic keys, authentication tokens, filesystem data and information belonging to other processes. The researchers selected `/etc/shadow` as a recognizable demonstration of protected information, not as the only possible target. The broader impact is arbitrary privileged-memory disclosure under the demonstrated conditions.

Systems that depend entirely on software isolation to protect extremely sensitive secrets should consider using hardware-backed key storage. Trusted platform modules, hardware security modules and external signing services can keep private keys outside ordinary kernel memory or limit their exposure. These controls do not solve speculative execution generally, but they reduce the number of high-value secrets available to a successful memory-disclosure attack.

The disclosure also reinforces the need to keep BIOS, UEFI and processor microcode current. Speculative-execution mitigations frequently require coordination between processor firmware and the operating system. Installing only kernel updates may leave hardware protections incomplete, while updating firmware without the matching operating-system changes may fail to enable the intended defence. Enterprises should track processor microcode as part of normal vulnerability management rather than treating firmware as an occasional hardware-maintenance concern.

Performance impact remains an unavoidable consideration. Spectre mitigations introduced since 2018 have sometimes reduced system performance, particularly for workloads involving frequent kernel transitions, system calls and context switches. Stronger interrupt and predictor barriers could impose additional overhead. Vendors will need to balance security with operational performance, but organizations should assess the risk according to workload sensitivity rather than disabling mitigations globally for benchmark improvements.

High-performance computing, database and trading environments may be particularly sensitive to mitigation overhead, yet they may also process valuable secrets and allow multiple users to share expensive hardware. These organizations should benchmark vendor fixes in realistic workloads and use selective isolation where the performance cost cannot be accepted universally. Disabling protections without compensating controls simply converts measurable latency into less measurable risk.

TONTOU should not be presented as evidence that all Spectre mitigations are useless. Existing protections block many earlier attack techniques and substantially increase the difficulty of exploitation. The new research instead demonstrates that one shared assumption within neutralization-based designs can be violated under specific conditions. Security engineering progresses by identifying these gaps and refining protections rather than declaring previous defences worthless whenever a new bypass appears.

The attack also remains technically demanding. It requires local code execution, careful timer configuration, alignment with extremely short execution windows, suitable predictor-poisoning techniques and repeated sampling to reconstruct data. The proof of concept succeeded only in half of the attempts to locate `/etc/shadow`, and its leak rate was measured in bytes per second. Ordinary cybercriminal operations are therefore more likely to prefer simpler privilege-escalation vulnerabilities when available.

However, technical difficulty should not be confused with irrelevance. Advanced attackers targeting shared infrastructure, high-value research systems or sensitive government environments may be willing to invest time in a stealthy memory-disclosure technique. Public research also provides a foundation on which later work may improve speed, reliability and portability. Many attacks that begin as difficult academic demonstrations become more practical as researchers and adversaries refine them.

The broader cybersecurity lesson from TONTOU is that security controls must protect the entire lifetime of trusted state, not merely the moment when that state is created or cleaned. Neutralizing a branch predictor is insufficient when interrupts, exceptions or other asynchronous events can modify it before the protected branch consumes it. The same principle applies throughout security architecture: a check or reset provides little assurance when an attacker can change the relevant state during the interval that follows.

TONTOU exposes a fundamental tension in modern processors. Operating systems require interrupts to remain responsive, while speculative-execution mitigations require predictor state to remain stable across sensitive transitions. The processor is expected to react immediately to asynchronous events while simultaneously preserving a security boundary built around precise control-flow assumptions. Attackers succeed by finding the narrow space where those requirements conflict.

Organizations should follow vendor guidance, deploy kernel and firmware updates, reduce opportunities for untrusted local code execution and isolate especially sensitive workloads. They should also understand that speculative-execution risk cannot be eliminated solely through endpoint scanning or application patching. It exists at the boundary between processor design, operating-system behaviour and workload placement.

The researchers’ ability to recover Linux password hashes despite current Spectre v2 protections does not represent an immediate universal compromise of AMD and Intel systems. It does demonstrate that a mitigation can perform its intended cleaning step correctly and still fail because the processor state is altered a few instructions later.

In security, the interval between protection and use is still part of the protection. TONTOU shows what happens when that interval is treated as empty simply because it is very small.

Researchers found a way to bypass recent mitigations for Spectre v2 speculative execution side-channel attacks and developed an exploit to leak secrets from Linux machines. [...]

Source: New TONTOU CPU attack bypasses Spectre v2 fixes, leaks Linux password hashes via Bleeping Computer — published 06 Aug 2026.