A precisely timed interrupt exposed a gap in Spectre defenses

The discovery

Modern Spectre defenses clean or isolate branch-prediction state before protected code uses it. The study asked whether an attacker could contaminate that state again during the unavoidable interval between those two events.

The research question and why it matters

Spectre v2 attacks manipulate speculative branch prediction so protected code transiently follows an attacker-chosen path. Later defenses attempted to sanitize or isolate predictor state at privilege boundaries or immediately before a protected branch. TONTOU shifts attention from whether that cleanup occurs to whether the state can be altered again before it is consumed.

What researchers found

Interrupts could trigger branch mispredictions after several protections had already neutralized predictor state. The end-to-end Zen 2 demonstration leaked kernel memory at an average 5.47 bytes per second with 91.97% accuracy. After first defeating address randomization, the researchers located the Linux /etc/shadow password-hash file in five of ten attempts.

Results at a glance

Key results from the tested systems

processor platforms tested

Two Intel and two AMD generations were used to test whether interrupts could cause post-cleanup mispredictions.

5.47 B/s

average leak rate

The end-to-end arbitrary kernel-memory leak was measured on an AMD Zen 2 system.

5 of 10

password-file location attempts

The researchers found /etc/shadow in half of their reported end-to-end attempts.

How the research worked

The researchers scheduled high-resolution timer interrupts from an unprivileged program so the Linux kernel's interrupt handler ran inside carefully targeted post-neutralization windows. They tested whether this interrupt execution could retrain branch-prediction structures on four Intel and AMD platforms. On an AMD Zen 2 system, they then combined the timing method with established side-channel techniques to locate the kernel and leak arbitrary kernel memory.

Subjects or systemLaboratory

Research designComputer-security systems experiment and end-to-end exploit

Evidence baseFour processor platforms spanning Intel Cascade Lake Refresh and Arrow Lake plus AMD Zen 2 and Zen 4; the complete memory-leak demonstration ran on AMD Zen 2

How to interpret this design

A controlled experiment can isolate a mechanism under defined conditions. The tradeoff is external validity: performance in a laboratory system may change when materials, organisms, environments or operating constraints differ.

The evidence comes from a controlled physical or chemical system. That control helps establish what happened under the tested conditions, while scale-up, durability, manufacturing and real-world performance remain separate questions.

What strengthens or limits the finding?

The researchers demonstrated the timing primitive on four recent processor platforms and built a working kernel-memory exploit on one AMD Zen 2 system. That directly establishes the vulnerability under the tested configurations, but not equal exploitability across every processor, operating system or workload.

The result is meaningfully informative, but identifiable limitations could alter the size, reach or causal interpretation of the finding.

Funding and disclosure context

The recorded funding source is: U.S. Air Force Office of Scientific Research and ACE, a JUMP 2.0 center sponsored by the Defense Advanced Research Projects Agency. The recorded conflict information is: No competing-interest statement was identified in the open conference paper. Funding or a disclosed relationship does not by itself invalidate a result, but it is relevant when judging design choices, analysis and the need for independent replication.

What it means

The result identifies a class of time-of-neutralization-to-time-of-use, or TONTOU, failures. A defense cannot assume that a cleaned processor state stays clean until use when interrupts can insert attacker-influenced execution in between. The practical lesson is narrower than 'processors are broken': operating-system and chip mitigations must account for what happens during this small transition window.

Beyond the abstract

Deeper analysis

The important gap is conceptual, not merely fast

Some defenses were designed around a clean-then-use sequence: clear dangerous prediction history, then execute the protected branch. TONTOU shows that security depends on the entire interval, even when that interval is only a few instructions. An interrupt is legitimate operating-system behavior, but here it also became a route for rebuilding attacker-useful predictor state.

The demonstration is serious but conditional

The attack begins with code already running on the machine at ordinary user privilege. That matters for shared servers, cloud systems and machines executing untrusted local code, but it is different from a drive-by remote compromise. The exact processor, kernel, mitigation and available code gadgets determine whether a misprediction can become a useful data leak.

Coordinated disclosure changes the practical risk

The researchers notified AMD and Intel months before publication and coordinated with Linux maintainers. AMD's public bulletin attributes the issue to the Linux Safe RET implementation and lists Zen 1 through Zen 4 as affected products while distinguishing demonstrated from suggested exposure. Readers should follow current operating-system and vendor guidance rather than treating the experimental configuration as a permanent description of every system.

Keep the claim in proportion

What it does NOT prove

It does not show that a remote website can automatically extract a phone or laptop's password file; the demonstrated attack required the ability to run unprivileged code on the target Linux system.
It does not establish the same end-to-end exploit on every Intel and AMD processor tested. The complete arbitrary-memory leak was demonstrated on AMD Zen 2.
It does not mean all Spectre defenses are useless. The work identifies a specific assumption that some neutralization-based defenses failed to preserve.

Important limitations

The end-to-end exploit depended on a specific AMD Zen 2 processor, Linux configuration and available disclosure gadgets.
Results differed across processor generations even when the nominal protection had the same name, which limits broad hardware-level generalization.
The leak was slow and the password-file location step succeeded in half of the reported attempts, so reliability depends on the target environment.
Vendor and operating-system mitigations can change after coordinated disclosure, making exploitability a moving target.

How this fits with previous research

Questions still unanswered

Which neutralization-based defenses on other processors expose exploitable post-cleanup windows?
Can vendors close those windows without a significant performance penalty?
How reliably can the technique cross virtual-machine or cloud-tenant boundaries in realistic deployments?
Will a second cleanup after interrupt handling remain effective across Intel and AMD microarchitectures?

Government verification and context

Relevant U.S. government resources

These resources serve different purposes. A registry can verify what researchers planned, a repository can locate government-funded work, and an agency page can supply authoritative background. None automatically proves that this paper's conclusion is correct.

Government repositoryU.S. Department of Energy, Office of Scientific and Technical Information

OSTI.GOV research search ↗

DOE's research repository is used to locate related national-laboratory reports, accepted manuscripts and funding-linked technical work.

Reuse note: Facts and discoveries are summarized here in original language. We link to government material instead of copying it wholesale, and we do not reuse agency logos, photographs, charts or third-party material unless the specific reuse rights are verified.

Sources and provenance