New "Interrupt Injection" Attack Slips Past Modern CPU Spectre Defenses

Executive Overview

The vulnerability stems from a novel class of race conditions conceptualized by the researchers as TONTOU (Time-of-Neutralization to Time-of-Use). Much like traditional software-based TOCTOU (Time-of-Check to Time-of-Use) vulnerabilities, TONTOU exploits a microscopic temporal gap. Specifically, it targets the fragile window of execution between the moment a processor sanitizes its branch predictor to defend against Spectre attacks, and the precise moment the kernel actually utilizes that cleaned state.

By timing a hardware interrupt to land squarely within this vulnerability window, an unprivileged user-space program can effectively re-poison the processor’s branch predictor after the defense mechanism has already run. This effectively neutralizes the software-based hardware protections.

Demonstrating the severity of the threat, the MIT researchers successfully executed the attack on an AMD Zen 2 machine running Linux 6.14, with every default Spectre v2 mitigation enabled. The exploit successfully leaked arbitrary kernel memory at a rate of 5.47 bytes per second with an astonishing 91.97% accuracy. Most alarmingly, this was sufficient to locate and read /etc/shadow—the system file housing local user password hashes—in five out of ten attempts. Because the attack requires no elevated privileges and only local code execution, it poses a significant threat to shared multi-tenant systems, cloud infrastructure, and enterprise servers utilizing affected processors.

Detailed Chronology & Technical Breakdown

The Mechanics of TONTOU and Interrupt Injection

Modern CPU architectures rely heavily on branch prediction to speed up execution pipelines, guessing which code paths a program will take next. However, malicious actors can manipulate these predictors (a process called "training") to force speculative execution along unauthorized paths, leaking sensitive data from the kernel—the core exploit vector known as Spectre v2.

To combat this, chipmakers and operating system maintainers developed isolation and sanitization defenses. Intel clears branch predictor states upon kernel entry using features like eIBRS and Branch History Buffer (BHB) clearing loops. AMD, conversely, addresses the vulnerability via "Safe-RET" (SRSO—Speculative Return Stack Overflow mitigations), which sanitizes the return stack buffer immediately before each kernel return.

These defenses share a single, critical assumption: that nothing hostile executes between the moment of sanitization and the moment of use.

Trujillo and Yan realized that hardware interrupts shatter this assumption. Because interrupts can fire asynchronously at virtually any microarchitectural moment—and because modern operating systems like Linux permit user-space applications to schedule or influence interrupt flows with nanosecond granularity—they present an ideal vector for interference.

If an interrupt handler executes between the system’s "neutralization" phase and its "use" phase, the resulting interrupt-return path becomes an unintended part of the Spectre v2 defense pipeline. On an AMD Zen 2 processor, this critical vulnerability window is minuscule: just two instructions, spanning a mere six bytes.

How the Exploit Works in Practice

To weaponize this microscopic window, the MIT researchers had to devise clever workarounds to dramatically improve their odds:

1. Window Widening: The researchers evicted the target instructions from the L1 and L2 caches by running tasks on a sibling hyperthread, effectively slowing down the processor’s execution pace.
2. System Call Manipulation: They targeted the write system call, as it left them in control of specific CPU registers during the critical execution phase.
3. Interrupt Timing: Through meticulous tuning, the researchers coaxed interrupts to land inside the target window between 5% and 12% of the time (dropping to roughly 2% when specific register constraints were enforced).
4. Re-Poisoning via Inception: Once an interrupt successfully landed inside the window, the interrupt handler itself transformed into a training gadget. Armed with Inception (CVE-2023-20569)—a prominent 2023 AMD hardware flaw that Safe-RET was specifically engineered to block—the attack filled the return stack buffer with an attacker-chosen target.

When tested across various hardware platforms, mispredictions successfully manifested in kernel code on three of the four tested machines. Success rates sat at 0.75% on AMD Zen 2, 0.22% on Intel Arrow Lake, and 0.037% on Intel Cascade Lake Refresh. Zen 4 produced no mispredictions in that specific test, and no end-to-end memory leak was explicitly demonstrated on Intel hardware (where an attacker would additionally require a viable disclosure gadget pre-existing within the kernel).

Nevertheless, the researchers emphasize that mispredictions are merely "a necessary but not sufficient condition for a Spectre attack." Because prior literature has repeatedly proven that disclosure gadgets exist within standard kernels, the researchers maintain that an end-to-end attack on Intel architectures remains entirely feasible by pairing their Interrupt Injection primitive with known techniques.

Supporting Context & Metrics

The academic rigor behind the INTERRUPT INJECTION discovery is underscored by the precise quantitative metrics achieved during controlled testing phases:

• Data Leakage Rate: 5.47 bytes per second.
• Extraction Accuracy: 91.97%.
• Privilege Requirement: Zero (requires local, unprivileged code execution only).
• Target Isolation Breach: Successfully extracted sensitive password hash data from /etc/shadow in 50% of real-world test runs (5 out of 10 attempts).
• Vulnerability Window: 2 instructions / 6 bytes (on AMD Zen 2 architecture).
• Interrupt Landing Probability: 5% to 12% baseline window hit rate under cache-eviction optimization; ~2% with full register control.
• Hardware Cross-Section: Demonstrated explicitly on AMD Zen 1 and Zen 2; Zen 3 and Zen 4 are flagged as theoretically vulnerable based on microarchitectural design similarities. Mispredictions were additionally documented on Intel Arrow Lake and Cascade Lake Refresh.

Official Statements and Industry Response

The vulnerability disclosure timeline unfolded across the early months of 2025, culminating in public patches and academic presentations:

• February 5, 2025: MIT CSAIL researchers formally disclosed the vulnerability details to both AMD and Intel.
• June 2, 2025: AMD engineers Borislav Petkov and David Kaplan authored a critical Linux kernel patch titled "x86/bugs: Make Safe-RET robust against interrupt injection" (Commit ID: f5fdd6665ac4d8528ed1c9242cb1cf7a7f5bdb0e). The commit explicitly mirrors the researchers’ findings, noting that injecting interrupts while Safe-RET executes "can neutralize the safe return sequence, potentially leading to data leakage through speculative execution." The patch adjusts register states as though the Safe-RET sequence had completed entirely, successfully avoiding the execution of a RET instruction post-interrupt return.
• August 6, 2025: AMD published security bulletin AMD-SB-7061, titled "Safe RET Interrupt Vulnerability," identifying Zen 1 through Zen 4 processors as affected products. The bulletin credits Daniël Trujillo and notes that the issue "appears to be associated with the Linux implementation of the Safe RET mitigation."
• Intel’s Position: According to the MIT research paper, Intel does not currently consider a software or microcode mitigation necessary for its processors. Intel argued that exploitability depends heavily on myriad systemic factors and asserted that the technique is sufficiently covered by existing architectural guidance, such as advisory INTEL-SA-00598. However, independent reviews of Intel’s security documentation (including updates through mid-2025) reveal no explicit mention of interrupt-based branch injection vulnerabilities. Intel did, however, issue a discretionary bug bounty bonus to the researchers.

Transparency and Tracking Gaps

A notable friction point highlighted by the disclosure is the lack of standardized tracking identifiers. Neither AMD’s official security bulletin nor MIT’s initial announcements directly linked to the specific Linux kernel commit addressing the flaw. Furthermore, because the vulnerability shipped without a dedicated Common Vulnerabilities and Exposures (CVE) identifier or prominent kernel release tags, system administrators face unnecessary friction.

Checking whether a machine carries the relevant fix requires deep familiarity with specific kernel commit subjects. Compounding this, the standard kernel status reporting file (/sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow) offered no visibility or documentation regarding interrupt vulnerabilities at the time of the initial August disclosures.

Future Outlook

The public unveiling of the INTERRUPT INJECTION technique at the Black Hat USA conference, alongside its formal presentation at the USENIX Security symposium in Baltimore, marks a critical turning point for hardware-software co-design security.

For years, hardware mitigations like AMD’s Safe-RET and Intel’s eIBRS have operated under the comfortable fiction that the operating system’s execution pipeline remains uninterrupted during delicate state-sanitization routines. The TONTOU class of vulnerabilities decisively shatters this paradigm, proving that asynchronous events like hardware interrupts can be weaponized to bypass state-of-the-art defenses.

Moving forward, CPU manufacturers and OS kernel maintainers must fundamentally rethink how security boundaries handle asynchronous control flow transfers. While the Linux kernel has swiftly integrated a robust countermeasure via Borislav Petkov and David Kaplan’s patch, the ecosystem-wide adoption of these fixes remains fragmented due to the absence of unified CVE tracking and clear vulnerability reporting metrics.

As multi-tenant cloud environments continue to densify and shared hardware infrastructures scale, security researchers will undoubtedly probe deeper into the temporal gaps between microarchitectural sanitization and operational use—forcing the industry to move beyond static defense assumptions toward truly interrupt-resilient processor architectures.