// 1 CRITICAL · 2 ZERO-DAY · 3 CVE · 3 EXPLOIT · 1 ADVISORY IN THE LAST 24H
MIT CSAIL researchers Daniël Trujillo and Mengjia Yan presented the Interrupt Injection technique at Black Hat USA 2026, demonstrating how an unprivileged Linux program can bypass Spectre v2 mitigations on Intel and AMD processors. Disclosure to vendors occurred on February 5, 2026. AMD acknowledged the vulnerability in bulletin AMD-SB-7061 on August 6, while Intel stated it will not add further mitigations. The technique has no CVE identifier, forcing administrators to manually verify a specific kernel patch.

MIT CSAIL researchers Daniël Trujillo and Mengjia Yan presented the Interrupt Injection attack at Black Hat USA 2026, a technique that allows an unprivileged Linux program to bypass Spectre v2 defenses on Intel and AMD processors. Vendor disclosure occurred on February 5, 2026. AMD acknowledged the vulnerability in bulletin AMD-SB-7061 on August 6, while Intel stated it will not add further mitigations. The technique has no CVE identifier, forcing administrators to manually verify the presence of a specific kernel patch.

Key Takeaways
  • An unprivileged Linux program can inject a hardware interrupt into the temporal window between branch predictor sanitization and its use, re-poisoning the predictor after the defense has already run.
  • On AMD Zen 2 with Linux 6.14 and all Spectre v2 mitigations active, researchers read /etc/shadow in 5 of 10 attempts with a leak rate of 5.47 bytes/s and 91.97% accuracy.
  • AMD published bulletin AMD-SB-7061 listing Zen 1 through Zen 4 processors as affected; Intel provides no additional guidance, deeming existing Spectre v2 and BHI/IMBTI measures sufficient.
  • The mitigation is a specific kernel commit dated June 2, 2026 with no associated CVE: administrators must manually verify the presence of "x86/bugs: Make Safe-RET robust against interrupt injection".

How the Two-Instruction Window Injection Works

The technique exploits a hardware-software race condition in branch predictor sanitization. Spectre v2 defenses — Safe-RET on AMD, eIBRS on Intel — assume the predictor neutralization operation and its subsequent use by the kernel are atomic. Interrupt Injection demonstrates that hardware interrupts can land in this temporal window.

On AMD Zen 2 the window spans two instructions, six bytes. Researchers use high-precision timers to align the interrupt; the interrupt handler then becomes a training gadget via Inception (CVE-2023-20569, CVSS 4.7 MEDIUM per NVD), filling the Return Stack Buffer with attacker-chosen targets. Subsequent speculation uses the "re-poisoned" predictor to divert execution toward disclosure gadgets.

Interrupts land in the window in 5–12% of cases; in roughly 2% of those, registers fall under attacker control. L1/L2 cache eviction occurs via a sibling hyperthread, slowing execution to increase success probability.

"An unprivileged Linux program can time a hardware interrupt to land in the gap between a processor sanitizing its branch predictor and the kernel using it, re-poisoning the predictor after the defense has run." The Hacker News, summarizing the MIT CSAIL research

Exfiltration Numbers: 5.47 Bytes/s and /etc/shadow in Five of Ten Attempts

Researchers demonstrated an end-to-end leak on AMD Zen 2 with Linux 6.14. The exfiltration rate is 5.47 bytes/s with 91.97% accuracy. Reading /etc/shadow succeeded in 5 of 10 attempts. According to Tom’s Hardware Italia, each KASLR bypass attempt takes approximately 9 minutes.

The observed misprediction rate varies significantly across tested microarchitectures: 0.75% on Zen 2, 0.22% on Intel Arrow Lake, 0.037% on Intel Cascade Lake Refresh. No mispredictions were detected on Zen 4 in the specific test, although AMD includes this generation in its vulnerability bulletin. Researchers did not demonstrate an end-to-end leak on Intel but believe combining it with prior disclosure gadget work is feasible.

Vendor Response: AMD Acknowledges, Intel Waits

AMD published bulletin AMD-SB-7061 "Safe RET Interrupt Vulnerability" on August 6, 2026, listing Zen 1 through Zen 4 processors as affected. The kernel mitigation commit, dated June 2, 2026 and authored by AMD’s Borislav Petkov and David Kaplan, describes the attack in terms identical to the research: "injecting interrupts while Safe-RET runs can neutralize the safe return sequence, potentially leading to data leakage through speculative execution".

Intel has taken a different stance. Jerry Bryant, Senior Director of Intel Product Assurance and Security, told The Hacker News that "Intel's assessment is that the behavior is related to BHI/IMBTI scenarios which are addressed by Intel's existing Spectre v2 and BHI/IMBTI guidance. Intel has not observed a real-world end-to-end attack on Intel processors and does not plan to add any additional mitigation guidance at this time." Bryant noted Intel awarded a discretionary bug bounty bonus but did not update advisory INTEL-SA-00598, last updated May 2025. Arm, for its part, considers the behavior does not provide direct deterministic control over branch targets.

Why the Missing CVE Is an Operational Problem

The absence of a CVE identifier for Interrupt Injection is not a formality. Patch management tools, compliance frameworks, and vulnerability management systems rely on standard identifiers to track remediation status. Without a CVE, a June 2, 2026 kernel commit remains invisible to automated pipelines.

Administrators must manually verify the presence of the commit "x86/bugs: Make Safe-RET robust against interrupt injection" in their kernels. No source in the dossier indicates which stable Linux release or distribution includes this commit. The visibility gap is itself a vulnerability in the disclosure process: environments that assume they are protected by Spectre v2 mitigations may not be, with no tools to detect it.

This scenario is particularly critical for multi-tenant cloud providers, CI/CD platforms with shared runners, VDI environments, and container hosts with shared kernels. In all these cases, isolation between tenants or jobs depends on the actual effectiveness of Spectre v2 defenses. If an unprivileged process can re-poison the branch predictor, the threat model underlying these architectures requires revision.

What to Do Now

  • Manually verify the presence of the kernel commit "x86/bugs: Make Safe-RET robust against interrupt injection" dated June 2, 2026 in your Linux systems, consulting the change logs of the distribution in use.
  • Consult AMD bulletin AMD-SB-7061 to determine whether Zen 1–Zen 4 processors in production fall within the affected population and whether updated microcode is available from the platform vendor.
  • Re-evaluate the isolation model for multi-tenant workloads, considering that active Spectre v2 mitigations may not guarantee protection against a local attacker with precise timing capabilities.
  • Monitor the publication of the MIT CSAIL paper at USENIX Security and any retrospective CVE assignment, which would enable integration into vulnerability management systems.

FAQ

Does the attack work remotely?

No. The dossier explicitly documents that the technique requires only local unprivileged code execution: "needs no privileges, only local code execution".

Will Intel release a patch?

At present, Intel does not plan additional mitigations. The official position, expressed by Jerry Bryant, is that existing guidance for Spectre v2 and BHI/IMBTI is sufficient.

Is Zen 4 immune?

Immunity is neither demonstrated nor confirmed. In the researchers’ specific test no mispredictions were detected on Zen 4, but AMD includes this generation in bulletin AMD-SB-7061 as affected.

The Interrupt Injection case revives a recurring tension in processor security: software mitigations assume ideal hardware behavior, but silicon’s temporal micro-arbiters introduce windows the abstract model does not capture. AMD chose to patch; Intel chose to observe. For those managing shared infrastructure, the divergence in vendor posture adds complexity to a verification already complicated by the absence of a trackable identifier.

Sources

Information has been verified against cited sources and is current as of publication.

Sources


Sources and references
  1. thehackernews.com
  2. securityarsenal.com
  3. tomshw.it
  4. thehackernews.uk