New Interrupt Injection Attack Bypasses Spectre v2 Defenses on Intel and AMD CPUs

For nearly a decade, the security industry has treated Spectre as a solved problem, at least in practical terms. Since its disclosure in 2018, CPU vendors, operating system developers, and cloud providers have deployed layer upon layer of mitigations intended to prevent speculative execution attacks from leaking sensitive data across privilege boundaries. Modern Linux systems running Intel and AMD processors now ship with numerous protections enabled by default, including Enhanced Indirect Branch Restricted Speculation (eIBRS), SafeRET, Branch History Injection (BHI) mitigations, Return Stack Buffer (RSB) management, and other kernel hardening techniques.

A new study from researchers at MIT’s Computer Science and Artificial Intelligence Laboratory (CSAIL), however, demonstrates that these defenses rely on a fundamental assumption that is not always true.

Rather than attacking speculative execution directly, the researchers found a way to exploit the brief period between the moment a processor sanitizes its branch prediction state and the moment that sanitized state is actually used. By precisely timing hardware interrupts during this tiny execution window, an attacker can effectively undo the mitigation before it takes effect, allowing speculative execution attacks that were previously believed to be blocked.

The technique, named Interrupt Injection, represents a new class of transient execution attack. Instead of discovering another flaw in branch prediction hardware, it exploits a timing gap in software mitigations themselves. The researchers refer to this broader category as TONTOU, short for Time-of-Neutralization to Time-of-Use, drawing an analogy to the well-known Time-of-Check to Time-of-Use (TOCTOU) race conditions that have plagued software for decades.

Their findings show that even well-designed mitigations can fail when assumptions about execution order no longer hold.

A Different Way to Break Spectre Defenses

Spectre attacks fundamentally rely on speculative execution, a performance optimization used by virtually every modern processor.

To maximize instruction throughput, CPUs attempt to predict the future. Rather than waiting for every branch condition to be resolved, the processor guesses which execution path will be taken and begins executing instructions ahead of time. If the prediction proves correct, performance improves significantly. If it proves incorrect, the architectural results are discarded.

Unfortunately, while architectural state is rolled back after a misprediction, many microarchitectural effects are not. Cache contents, branch predictor state, return stack entries, translation lookaside buffers, and other internal structures retain evidence of speculative execution. Attackers can later measure these side effects through timing differences and reconstruct information that should never have been accessible.

This observation formed the basis of the original Spectre attacks disclosed in 2018. Spectre Variant 2, also known as Branch Target Injection (BTI), specifically abuses indirect branch prediction. Instead of influencing program data, an attacker trains branch prediction hardware so that privileged code speculatively jumps to an attacker-controlled sequence of instructions known as a gadget. Although speculative execution is eventually discarded, the gadget leaves measurable traces in the processor cache, allowing secrets to be inferred.

Over the years, CPU vendors introduced multiple layers of protection against these attacks. Intel implemented mechanisms such as eIBRS, Branch History Injection controls, Indirect Branch Prediction Barrier (IBPB), and Single Thread Indirect Branch Predictors (STIBP). AMD introduced SafeRET to defend against Speculative Return Stack Overflow (SRSO), a vulnerability publicly disclosed in 2023 as CVE-2023-20569, also known by its research name, Inception.

Despite their differences, these mitigations all follow the same basic philosophy. Before privileged execution relies on branch prediction hardware, the processor either sanitizes, isolates, or replaces potentially attacker-controlled prediction state. Once that sanitization completes, execution proceeds under the assumption that prediction hardware is now trustworthy. Interrupt Injection challenges that assumption.

The Critical Timing Window

Instead of trying to bypass mitigations after they complete, MIT researchers Daniël Trujillo and Mengjia Yan focused on something much smaller: the tiny gap between mitigation and execution.

Although mitigation code may execute correctly, there remains a brief period before the protected return instruction or indirect branch actually consumes the sanitized predictor state. On modern processors, this window can be only a handful of instructions long.

Ordinarily such a narrow interval would appear impossible to exploit. Hardware interrupts change that. Unlike software events, hardware interrupts can occur at almost any instruction boundary. Linux also exposes several interfaces that allow ordinary users to trigger extremely precise timer interrupts with nanosecond-level granularity. These timers are intended for legitimate high-resolution scheduling but also provide attackers with remarkably accurate control over interrupt timing.

If an interrupt arrives during the tiny interval between predictor sanitization and its eventual use, execution temporarily leaves the mitigation sequence. The interrupt handler itself executes kernel code. That kernel execution updates branch prediction structures. When control finally returns to the interrupted mitigation sequence, the predictor state is no longer the sanitized state the kernel expected. It has been modified by the interrupt handler. In effect, the protection has already been undone before it is ever used.

The researchers compare this to classic race conditions in operating systems. A program may validate a file before opening it, assuming nothing changes between validation and use. If another process modifies the file during that interval, the original safety check becomes meaningless Interrupt Injection applies exactly the same concept to speculative execution defenses. Instead of racing filesystem state, attackers race branch predictor state.

Introducing TONTOU

The researchers describe this broader vulnerability pattern as Time-of-Neutralization to Time-of-Use, abbreviated as TONTOU.

Existing Spectre mitigations generally follow two sequential steps. First, they neutralize attacker influence over branch prediction structures. Second, they execute privileged instructions that depend on those structures. Every current mitigation assumes nothing hostile executes between those two steps.

Hardware interrupts violate that assumption. Unlike ordinary function calls, interrupts are asynchronous by design. The processor may suspend execution almost anywhere, preserve architectural state, execute an interrupt handler, and then resume execution precisely where it stopped.

If that interrupt handler itself updates prediction hardware, the earlier neutralization is no longer guaranteed to remain valid. This is not a flaw in interrupt handling itself. Interrupts are functioning exactly as intended. The flaw lies in assuming that mitigation and protected execution occur atomically when, in reality, interrupt delivery makes that assumption false. The researchers argue that any speculative execution defense relying on this assumption should be examined for similar timing vulnerabilities.

AMD SafeRET Under the Microscope

AMD’s SafeRET mitigation was introduced following the disclosure of Inception, a speculative execution attack affecting Zen processors.

Inception exploited the processor’s Return Stack Buffer (RSB), a hardware structure that predicts function return addresses. By deliberately causing the RSB to underflow and manipulating branch prediction behavior, attackers could redirect speculative execution into carefully selected gadgets.

SafeRET prevents this by replacing ordinary return sequences with a safer software implementation designed to ensure speculative execution cannot follow attacker-controlled predictions. For years, SafeRET was considered an effective mitigation against SRSO. Interrupt Injection demonstrates that SafeRET itself is vulnerable if execution is interrupted at precisely the wrong moment.

According to the researchers, the vulnerable execution window on AMD Zen 2 measures only two instructions, corresponding to six bytes of machine code. On paper, successfully interrupting such a narrow interval appears extraordinarily unlikely. The researchers therefore developed techniques to increase the probability.

Making an Impossible Race Practical

One challenge facing the researchers was time. Modern processors execute instructions extraordinarily quickly, meaning the vulnerable window exists for only a tiny fraction of a microsecond. To improve their chances, they deliberately slowed execution.

Using a sibling hyperthread running on the same physical core, they repeatedly evicted the instructions comprising the SafeRET sequence from both L1 and L2 instruction caches. Without cached instructions, the processor was forced to fetch them again from slower levels of the cache hierarchy, increasing the duration of the vulnerable window. Although the change measured only tens of processor cycles, those additional cycles substantially improved interrupt timing reliability.

The researchers also selected the Linux write() system call because its calling convention left two processor registers under attacker control immediately before entering the vulnerable sequence. Maintaining control over these registers later proved useful when steering speculative execution. With these optimizations, interrupts landed inside the vulnerable window between roughly 5% and 12% of attempts. Approximately 2% of those successful interrupts also preserved attacker-controlled register state, enabling the complete attack chain.

Those percentages may appear small, but speculative execution attacks rarely depend on a single successful attempt. Modern transient execution exploits routinely execute millions of iterations, gradually extracting information one bit at a time. Reliability is therefore determined by repetition rather than individual success.

Turning Interrupts into an Attack Primitive

Landing an interrupt during SafeRET is only the beginning. Once execution enters the interrupt handler, the researchers reuse techniques previously developed for the Inception attack. Instead of relying on ordinary branch prediction, they manipulate the Return Stack Buffer so speculative returns resolve to attacker-selected kernel gadgets. In other words, Interrupt Injection does not replace Inception. It revives it.

SafeRET was specifically designed to stop Inception by sanitizing return prediction immediately before returning from kernel mode. Interrupt Injection interrupts that sanitization process, allowing the original speculative attack to proceed.

This relationship is particularly important because it demonstrates that old transient execution techniques do not necessarily disappear after mitigations are deployed. In some cases, bypassing the mitigation restores the original attack with surprisingly few modifications.

Demonstrated Data Leakage

To validate the attack, the researchers implemented a complete proof-of-concept on an AMD Zen 2 system running Linux 6.14 with all default Spectre v2 mitigations enabled. Rather than measuring isolated speculative events, they demonstrated practical kernel memory disclosure. Their exploit achieved an average leakage rate of 5.47 bytes per second while maintaining approximately 91.97% reconstruction accuracy.

Although that bandwidth may appear slow compared to conventional memory disclosure vulnerabilities, speculative execution attacks have never relied on high throughput. Kernel secrets such as password hashes, cryptographic keys, authentication tokens, or address randomization values are typically small enough that even a few bytes per second can have serious security implications.

To illustrate this, the researchers successfully recovered the contents of /etc/shadow, the Linux file containing password hashes, in five out of ten experimental runs. Importantly, the attack required no elevated privileges. Execution of ordinary unprivileged local code was sufficient.

That makes the attack particularly relevant for multi-user Linux servers, shared academic systems, developer workstations, container hosts, continuous integration environments, and cloud infrastructure where mutually untrusted workloads may execute on the same physical processor.

Vendor Responses Highlight Different Risk Assessments

The researchers privately disclosed their findings to AMD and Intel on February 5, 2026, giving both vendors several months to evaluate the issue before its public presentation at Black Hat USA and the publication of the accompanying research.

AMD acknowledged the findings and published AMD-SB-7061, titled Safe RET Interrupt Vulnerability, on August 6. The advisory identifies processors based on the Zen 1, Zen 2, Zen 3, and Zen 4 microarchitectures as affected by the issue. AMD’s description emphasizes that a locally executing attacker could precisely time an interrupt to interfere with the Linux implementation of SafeRET, potentially weakening Spectre v2 protections and leading to information disclosure.

Notably, AMD characterizes the issue as being associated with the Linux implementation of the mitigation rather than a defect in the processor’s speculative execution hardware itself. That distinction matters because it places the primary remediation within the operating system rather than requiring new processor microcode.

Intel reached a different conclusion. According to the researchers, Intel determined that additional mitigation was not currently necessary, arguing that practical exploitation depends on several conditions already discussed in existing Spectre guidance. Intel reportedly awarded a discretionary bug bounty for the research but did not issue a new security advisory introducing additional protections.

This difference in response does not necessarily indicate disagreement about the underlying research. Instead, it reflects different assessments of practical exploitability, existing mitigations, and deployment priorities across processor families.

Why the Linux Kernel Required a Fix

The research highlights an important engineering lesson about speculative execution defenses. Most existing mitigations focus on ensuring that branch prediction structures are placed into a known, trusted state before sensitive execution resumes. The assumption is that once this state has been established, execution proceeds immediately using that sanitized predictor information. Interrupt Injection demonstrates that asynchronous events can violate this assumption.

The Linux kernel update addresses the issue by making the SafeRET sequence resilient even if execution is interrupted during the mitigation process. Rather than allowing execution to resume in a way that could reintroduce speculation along an unsafe return path, the updated logic ensures that execution continues as though the mitigation had already completed, preventing the vulnerable transition from occurring.

The kernel patch, titled “x86/bugs: Make Safe-RET robust against interrupt injection,” was merged on June 2, 2026. Authored by Borislav Petkov and co-developed with AMD engineer David Kaplan, the commit explicitly describes how interrupts occurring during SafeRET could neutralize the mitigation and potentially allow speculative information disclosure.

From a software engineering perspective, the patch effectively removes the race condition identified by the researchers. Rather than trying to prevent interrupts from occurring, which would be impractical and undesirable for a modern operating system, the kernel ensures that an interrupt can no longer invalidate the assumptions made by the mitigation sequence. This approach preserves normal interrupt handling while closing the timing window exploited by the researchers.

Understanding TONTOU Beyond This Vulnerability

Perhaps the most significant contribution of the research is not the specific attack against SafeRET, but the introduction of the broader TONTOU concept. Security engineers have long been familiar with TOCTOU vulnerabilities, where data validated at one point in time becomes invalid before it is later used. Filesystem race conditions, symbolic link attacks, and privilege escalation bugs frequently arise from this class of problem.

The MIT researchers argue that speculative execution mitigations can suffer from an analogous weakness. If a defense neutralizes attacker influence over microarchitectural state but assumes nothing changes before that state is consumed, asynchronous execution may invalidate the defense. Hardware interrupts are one example, but the broader lesson extends beyond a single mitigation or processor vendor.

Future transient execution defenses may need to account not only for what state is sanitized, but also for whether that state can change before it is actually relied upon. That represents an architectural consideration that could influence the design of future operating system mitigations and perhaps even processor hardware.

How Serious Is the Real-World Risk?

As with many speculative execution attacks, practical risk depends heavily on deployment environment.

The attack requires an adversary to execute local code on the target machine. It is not remotely exploitable through ordinary network traffic, nor does it allow an attacker to compromise a system without first obtaining code execution. That requirement significantly limits the threat for many desktop users.

However, environments where mutually untrusted workloads share the same physical processor remain more exposed. These include multi-user Linux servers, university computing clusters, continuous integration infrastructure, shared hosting platforms, containerized workloads, virtualization hosts, and some cloud deployments.

Speculative execution vulnerabilities have historically been most concerning in exactly these scenarios because isolation between users or workloads depends on hardware and kernel protections functioning correctly.

Although the demonstrated leakage rate is relatively low, information disclosure attacks often target small but valuable secrets rather than large volumes of data. Password hashes, authentication tokens, cryptographic material, address randomization values, and similar data sets may all be useful to an attacker even when extracted gradually.

The research therefore reinforces a familiar lesson from previous Spectre-class vulnerabilities: bandwidth is rarely the primary concern. Reliability and the sensitivity of the leaked information matter far more.

What Administrators Should Do

Organizations running Linux on affected AMD processors should ensure their systems are updated with a kernel containing the SafeRET interrupt injection fix.

Because the mitigation is implemented in the operating system, installing a patched kernel is the primary remediation recommended by AMD. Administrators should also continue following existing guidance for speculative execution vulnerabilities, including applying firmware and operating system updates promptly and maintaining current microcode where applicable.

Asset inventories should identify systems based on affected Zen processor generations so patch deployment can be prioritized appropriately. Enterprise environments with shared compute infrastructure, virtualization platforms, or container hosts should treat kernel updates as particularly important because those environments derive the greatest security benefit from strong isolation between workloads.

While no public evidence currently suggests widespread exploitation, speculative execution research has repeatedly shown that techniques initially demonstrated in academic settings often influence future attack research. Applying available mitigations before such techniques become operational remains the most effective defensive strategy.

A Reminder That Speculative Execution Research Continues to Evolve

Nearly a decade after Spectre fundamentally changed processor security, researchers continue to discover new ways of challenging assumptions that once appeared sound.

Interrupt Injection does not introduce a new speculative execution primitive in the traditional sense. Instead, it demonstrates that the correctness of a mitigation depends not only on the mitigation itself, but also on the execution environment surrounding it. Even carefully engineered defenses can become ineffective if seemingly unrelated mechanisms, such as interrupt delivery, alter processor state at precisely the wrong moment.

The work also illustrates how speculative execution research has matured. Rather than focusing solely on discovering new prediction mechanisms to manipulate, researchers are increasingly examining the assumptions underlying existing defenses and identifying subtle interactions between operating systems, processor behavior, and microarchitectural state.

For Linux users on affected AMD systems, the practical guidance is straightforward: install a kernel that includes the SafeRET interrupt injection fix and continue applying security updates as they become available. For the broader security community, the research serves as another reminder that mitigating speculative execution remains an ongoing process rather than a one-time engineering milestone.

As processors continue to grow more complex and software defenses become increasingly sophisticated, ensuring that mitigations remain correct under every possible execution path, including asynchronous events such as interrupts, will remain an important area of both academic research and operating system development.

FAQs