Interrupt Injection exposes a gap in Spectre v2 protections on Linux
MIT CSAIL researchers Daniël Trujillo and Mengjia Yan have disclosed Interrupt Injection, a technique that can bypass Spectre v2 defenses on Intel and AMD processors by timing a hardware interrupt during a narrow mitigation window. On an AMD Zen 2 computer running Linux 6.14 with default Spectre v2 protections enabled, their proof of concept leaked arbitrary kernel memory at 5.47 bytes per second with 91.97% accuracy.
The researchers reported that the exploit found and read /etc/shadow, the file containing password hashes, in five out of ten attempts. It requires no elevated privileges, but it does require local code execution. That makes shared systems running an affected processor the principal exposure scenario described in the research.
A race between predictor cleanup and use
Spectre v2 mitigations are intended to sanitize or isolate branch-predictor state so earlier attacker training cannot influence a subsequent kernel branch. Intel applies protections on kernel entry through eIBRS and, depending on the processor, a branch-history-buffer clearing loop or BHI_DIS_S. AMD applies its saferet mitigation immediately before a kernel return.
Trujillo and Yan call the broader condition TONTOU, or Time-of-Neutralization to Time-of-Use. Their point is that these defenses assume no hostile activity runs after predictor state is neutralized and before the kernel uses it. Hardware interrupts can occur in that interval, while Linux permits users to schedule them with nanosecond granularity.
On Zen 2, the relevant interval was two instructions, or six bytes. The team used a sibling hyperthread to evict those bytes from L1 and L2 cache, increasing the opportunity for an interrupt to arrive in the window. They selected the write system call because it left two registers under their control. Interrupts landed in the interval 5% to 12% of the time, and roughly 2% of the time with those registers attacker-controlled.
AMD bulletin and Intel position
AMD published AMD-SB-7061, “Safe RET Interrupt Vulnerability,” on August 6. It lists Zen 1 through Zen 4 processors as affected and says a precisely injected interrupt could disrupt Safe RET, potentially weakening the protection and allowing information disclosure. AMD states that the issue appears associated with Linux’s implementation of the mitigation.
The bulletin credits Trujillo and says the behaviour was demonstrated on Zen 1 and Zen 2; Zen 3 and Zen 4 are suggested but were not demonstrated in the bulletin. The paper reports testing on Zen 2 and Zen 4. AMD’s affected-products section provides neither a patch version, kernel commit nor CVE, leaving administrators without a direct identifier for determining whether a host has the update MIT says has shipped.
For the attack path, the interrupt handler becomes a training gadget using Inception, CVE-2023-20569, to fill the return stack buffer with an attacker-selected target. Inception is the 2023 AMD issue that saferet was intended to address. The researchers observed mispredictions on Zen 2, Intel Arrow Lake and Cascade Lake Refresh, but demonstrated no end-to-end leak on Intel. Zen 4 produced no mispredictions in that test.
Operational response
Intel paid a discretionary bug-bounty bonus but said it does not consider additional mitigation necessary, citing factors affecting exploitability and existing guidance. The researchers propose neutralizing predictor state again on interrupt exit, by stuffing the return stack buffer before iret or issuing IBHF on newer Intel processors. A related landscape of Linux kernel risks appears in Linux rootkits and router zero-day risks and shows why local execution assumptions deserve close review in shared environments.
Organizations should identify Linux systems using affected AMD generations, install current operating-system and kernel updates, and monitor vendor guidance for a verifiable patch identifier. Until that information is explicit, default Spectre v2 settings alone should not be treated as conclusive assurance for locally shared workloads.
Interrupt Injection: what Linux administrators should verify
Interrupt Injection is not a general remote compromise technique. The research describes a precisely timed local attack that targets a narrow interval between neutralising branch-predictor state and using it. This distinction matters when assessing shared Linux hosts and deciding whether existing Spectre v2 settings provide sufficient assurance.
Where the exposure matters
The scenario requires local code execution and is therefore most relevant to systems where potentially untrusted workloads share an affected processor. The reported proof of concept ran on AMD Zen 2 with Linux 6.14 and default Spectre v2 protections. AMD lists Zen 1 through Zen 4 as affected, although the level of demonstrated behaviour differs across generations in the bulletin and research described above.
- Prioritise Linux hosts that run code from multiple users or workloads.
- Record the processor generation, kernel version and active Spectre v2 mitigations.
- Do not treat default mitigation settings alone as proof that the timing window is closed.
A practical review checklist
Administrators can respond without assuming that every listed system is exploitable. Start with an inventory, apply current operating-system and kernel updates, and compare each host against guidance from the processor vendor and Linux distribution. The page notes that AMD’s bulletin did not provide a CVE, kernel commit or patch version, so update verification may require continued monitoring for a concrete identifier.
- Identify shared Linux systems using AMD Zen 1 through Zen 4 processors.
- Install current kernel and operating-system updates from trusted repositories.
- Check vendor and distribution advisories for a patch version or kernel commit.
- Reassess local code execution paths and workload isolation on shared hosts.
- Document the evidence used to mark each system as reviewed or remediated.
Frequently asked questions
What is Interrupt Injection?
Interrupt Injection is a research technique that times a hardware interrupt to reach a narrow window in a Spectre v2 mitigation sequence. In the demonstrated AMD Linux scenario, this could interfere with Safe RET and enable information disclosure.
Can Interrupt Injection be exploited remotely?
The scenario described in the research requires local code execution. Its principal relevance is therefore to shared systems where untrusted or less-trusted code can run on an affected processor.
Which processors should administrators review?
AMD’s bulletin lists Zen 1 through Zen 4. However, the reported demonstrations and observed behaviour vary by generation, so administrators should consult current processor-vendor and Linux-distribution guidance rather than assume identical exposure.
Is enabling default Spectre v2 protection enough?
Not necessarily. The proof of concept ran with default Spectre v2 protections enabled. Administrators should also verify current kernel updates, vendor guidance and workload-isolation assumptions.