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.