The newly disclosed TONTOU attack demonstrates that some of the mitigations developed to contain Spectre v2 can still be undermined by carefully manipulating what happens after the processor believes it has neutralized malicious branch-predictor state. Researchers Daniël Trujillo and Mengjia Yan of MIT CSAIL showed that an unprivileged local process can exploit this gap to influence speculative execution and leak privileged kernel memory on modern AMD and Intel processors. Their end-to-end proof of concept on AMD Zen 2 recovered arbitrary kernel memory at approximately 5.47 bytes per second with 91.97% accuracy, including data from Linux /etc/shadow, which stores password hashes normally accessible only to root.

The attack is called Time-of-Neutralization to Time-of-Use, or TONTOU, because it exploits a short window between the moment a mitigation sanitizes or isolates the CPU's branch-prediction state and the moment the protected branch actually consumes that state. Existing Spectre v2 defenses effectively assume that once the predictor has been neutralized, an attacker cannot meaningfully influence it before the sensitive indirect branch executes. The researchers show that this assumption is not always valid.

Their key technique is called Interrupt Injection. An unprivileged process schedules hardware timer interrupts so that the processor enters a kernel interrupt handler during this post-neutralization window. That interrupt path can affect branch-predictor structures and provide the attacker with an opportunity to re-poison predictor state after the mitigation has already performed its cleanup. The victim kernel then reaches the protected indirect branch with attacker-influenced prediction state restored.

This is a subtle but important failure mode. The mitigation itself may work exactly as intended at the instant it executes. The weakness exists because security is assumed to remain intact until the protected operation occurs. TONTOU shows that this interval can itself become an attack surface.

In simplified terms, the sequence becomes:

attacker poisons predictor → Spectre mitigation neutralizes state → attacker triggers interrupt during the gap → interrupt path re-poisons predictor → kernel resumes → protected branch mispredicts → speculative execution reaches attacker-selected gadget → secret influences microarchitectural state → attacker reconstructs secret

The breakthrough is not merely finding another Spectre gadget. It is finding a reliable mechanism to regain influence after the defense has supposedly removed that influence.

Spectre v2, also known as Branch Target Injection, relies on manipulating indirect branch prediction so that the CPU speculatively executes instructions along a path chosen indirectly by the attacker. Although the incorrect speculative path is eventually discarded architecturally, traces of that execution remain in microarchitectural structures such as caches. The attacker then measures those effects to infer data that should never have been accessible.

Since the original Spectre disclosure in 2018, processors, operating systems, and compilers have accumulated several layers of defenses including retpolines, IBRS and enhanced IBRS, IBPB, STIBP, return-stack protections, and other branch-predictor controls. Linux exposes their current status through /sys/devices/system/cpu/vulnerabilities/spectre_v2. These defenses attempt either to prevent poisoned prediction state from crossing security boundaries or to sanitize it before privileged code uses it.

TONTOU is important because it attacks that neutralization model itself.

The researchers demonstrated that apparently benign interrupts can create opportunities to modify predictor state between sanitization and use. Operating systems normally treat asynchronous interrupts as an ordinary and unavoidable part of execution. They occur constantly for timers, devices, scheduling, and other system functions. TONTOU demonstrates that this ordinary architectural behavior can interact with speculative execution in ways defensive assumptions did not fully account for.

The proof-of-concept result involving /etc/shadow understandably makes for a dramatic headline, but it needs careful interpretation. The researchers did not instantly recover a Linux root password in plaintext. They leaked kernel memory containing password-hash data from /etc/shadow. The password itself would still need to be recovered through offline cracking if an attacker wanted the original credential.

Even so, the security implication remains serious. A local unprivileged process is not supposed to read kernel memory at all, much less material associated with root credentials.

In the researchers' AMD Zen 2 testing, the end-to-end exploit successfully defeated Kernel Address Space Layout Randomization and attempted to locate /etc/shadow. Across ten test runs, the exploit successfully extracted the target file in five cases, with successful attempts taking around 18 minutes on average.

That detail is important because it frames the practical risk accurately. TONTOU is not a one-click privilege escalation where any remote attacker instantly becomes root. It requires local code execution, careful timing, suitable speculative gadgets, vulnerable processor behavior, and considerable technical sophistication.

The attack is nevertheless significant for environments where untrusted code routinely executes on shared hardware.

Multi-tenant systems are the obvious concern.

Cloud hosts, container platforms, build systems, shared development infrastructure, high-performance computing environments, browser or application sandboxes, and systems offering local shell access frequently allow code from mutually untrusted users to execute while sharing the same kernel and processor resources.

In those environments, “the attacker already needs local execution” is not necessarily reassuring. Providing controlled local execution is the entire service model.

A container, for example, may isolate filesystem, namespace, and process access but still share the host kernel. If an ordinary workload can exploit a microarchitectural side channel to read privileged kernel information, the logical container boundary may not provide the confidentiality the operator expects.

Trujillo specifically noted that multi-tenant container platforms represent a relevant scenario because ordinary user-space programs execute while sharing kernel infrastructure with other tenants and privileged services.

The result therefore reinforces a recurring lesson from speculative-execution research: software isolation depends on hardware behavior that traditional security models often assume is invisible.

Architecturally, an unprivileged application cannot read kernel memory.

Microarchitecturally, speculative execution can sometimes leave evidence of information that was never supposed to become architecturally visible.

That gap between architectural correctness and microarchitectural leakage is what has kept Spectre research alive for nearly a decade.

TONTOU also demonstrates why speculative-execution mitigations have become progressively more complicated. Every defensive mechanism interacts with branch predictors, privilege transitions, interrupts, context switches, simultaneous multithreading, return prediction, virtualization, and operating-system scheduling.

Fixing one attack primitive does not automatically eliminate every way the underlying prediction structures can be influenced.

The processor is still designed to predict aggressively because performance depends on it.

Security engineering is therefore attempting to place boundaries around machinery whose primary purpose is to make educated guesses before the software itself knows what should happen.

Occasionally the guesses escape their designated administrative area.

The AMD and Intel responses also differ.

AMD acknowledged the issue and indicated that it was associated with the Linux implementation of its Safe RET mitigation. The research led to Linux-side changes intended to close the relevant behavior.

Intel, meanwhile, says TONTOU behavior is related to previously documented Branch History Injection and Intra-Mode Branch Target Injection scenarios and that its existing guidance remains applicable. Intel says it has not observed a real-world end-to-end attack on Intel processors and does not currently plan additional mitigation guidance.

That difference should not be simplified into “AMD vulnerable, Intel safe.”

The researchers demonstrate the underlying TONTOU concept on both AMD and Intel systems, but the practical exploitability and required software conditions differ. Their fully developed arbitrary kernel-memory leakage demonstration targeted AMD Zen 2, while Intel exploitation involved additional constraints and complexity.

This distinction matters for security teams evaluating exposure.

A proof of concept against one CPU generation does not automatically mean every Intel and AMD processor can be exploited identically.

Administrators should rely on processor-vendor advisories, operating-system updates, and Linux kernel mitigation guidance rather than treating the research as a universal one-size-fits-all exploit.

Linux administrators should ensure that systems are running current kernels and CPU microcode and should verify the mitigation state reported by the kernel. The file:

/sys/devices/system/cpu/vulnerabilities/spectre_v2

provides information about the mitigations selected for the running system, including retpoline, enhanced IBRS, IBPB, and STIBP status where applicable.

The existence of TONTOU does not make these protections useless.

They continue to block large classes of speculative-execution attacks.

The research instead demonstrates that organizations cannot assume the presence of a mitigation label means the underlying class of attack has disappeared permanently.

For high-security environments, administrators should pay particular attention to workloads that execute untrusted code and share a kernel with valuable secrets.

Where practical, stronger isolation boundaries such as dedicated virtual machines or separate hosts can reduce the amount of sensitive information accessible through a shared microarchitectural environment.

Simultaneous multithreading policy may also deserve review in especially sensitive workloads, although the exact value of disabling SMT depends on the attack class and platform. There is rarely a pleasant universal answer with speculative-execution vulnerabilities because apparently processor security required the industry to rediscover the phrase “it depends” at transistor scale.

System hardening should also minimize valuable long-lived secrets in kernel-accessible memory wherever possible. Password hashes are one demonstrated target, but arbitrary kernel-memory leakage could theoretically expose other information depending on what is resident at the time: cryptographic keys, authentication tokens, pointers, security metadata, or data belonging to privileged processes.

The /etc/shadow demonstration should therefore be understood as proof of general kernel-memory disclosure, not merely as a password-file problem.

That is arguably the more important result.

If the attack primitive can leak arbitrary kernel memory, the specific secret recovered in the demonstration is simply the researchers' chosen evidence that the privilege boundary has failed.

The research also emphasizes the need to think differently about side-channel vulnerability severity. Traditional vulnerability scoring works well when an attacker sends a packet, triggers memory corruption, and obtains code execution.

Microarchitectural attacks are messier.

They may require local execution, precise timing, a compatible processor, repeated measurements, and carefully chosen gadgets. That reduces broad opportunistic exploitation but does not make the underlying security boundary failure trivial.

The risk is contextual.

On a single-user workstation where only trusted software executes, the attack may have limited practical relevance.

On a cloud host intentionally executing untrusted customer code alongside privileged services, the same primitive deserves substantially greater attention.

This is why deployment context matters more than dramatic headlines.

The defensive priority should therefore be highest for:

multi-tenant compute → container hosting → shared CI/CD runners → research or university shell servers → hosting environments → sandboxed execution platforms → systems where untrusted users can run native code

These are environments where the prerequisite of local code execution is part of normal operation rather than evidence that the attacker has already won.

The broader lesson from TONTOU extends beyond Spectre v2.

The researchers describe a general Time-of-Neutralization to Time-of-Use security problem.

A defense performs some cleansing, isolation, reset, or validation step and then assumes the protected state remains trustworthy until it is consumed.

If an attacker can influence the state during that interval, the defense can be bypassed even though the neutralization itself worked correctly.

That conceptual model may encourage researchers to search for similar windows elsewhere in processors and operating systems.

The security community is very familiar with Time-of-Check to Time-of-Use race conditions in software.

TONTOU applies a related idea to security mechanisms that neutralize microarchitectural state.

The implication is uncomfortable but useful:

clean state is not necessarily safe state if an attacker can modify it before use.

The TONTOU attack chain can be summarized as:

unprivileged local code → schedule precise interrupts → mitigation neutralizes branch predictor → interrupt executes during post-neutralization window → predictor re-poisoned → kernel indirect branch mispredicts → speculative gadget accesses privileged memory → cache side channel leaks data → attacker reconstructs kernel secrets

That chain is technically demanding.

But the researchers built it and demonstrated that it works.

The larger lesson is therefore not that every Linux server can suddenly have its root password stolen remotely in eighteen minutes.

That would be inaccurate.

The real lesson is more fundamental:

Spectre-era defenses are still built on assumptions about when attacker influence begins and ends, and TONTOU has shown that one of those assumptions can fail.

Eight years after Spectre first forced the industry to rethink speculative execution, processors are still teaching us the same irritating lesson: code that “never executed” can still leave evidence, and security boundaries implemented in software ultimately depend on what the hardware actually does rather than what the architecture says it should have done.

A new Branch Target Reuse (BTR) attack has been devised that can recover root password hashes on Intel computers running Linux in 3-5 minutes on average. [...]

Source: New Spectre v2 attack variant leaks Linux root password hash in minutes via Bleeping Computer — published 29 Sep 2026.