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.
MIT CSAIL researchers Daniël Trujillo and Mengjia Yan named the technique INTERRUPT INJECTION. On an AMD Zen 2 machine running Linux 6.14 with every default Spectre v2 mitigation on, their exploit leaked arbitrary kernel memory at 5.47 bytes per second with 91.97% accuracy, enough to locate and read /etc/shadow, which stores the system’s password hashes, in five of ten attempts.
It needs no privileges, only local code execution, so the risk sits on shared systems running an affected processor.
The pair disclosed to AMD and Intel on February 5. AMD told them it plans a kernel patch; MIT says one has since shipped and arrives in a normal operating system update.
A fix is in the Linux kernel. The commit, “x86/bugs: Make Safe-RET robust against interrupt injection”, is dated June 2 and was written by Borislav Petkov and co-developed with David Kaplan, both AMD engineers. It describes the attack in the same terms the researchers do: injecting interrupts while Safe-RET runs “can neutralize the safe return sequence, potentially leading to data leakage through speculative execution.”
The patch fixes up register state as though the Safe-RET sequence had completed, and avoids executing a RET instruction after the interrupt returns. That is one of the two routes the paper proposed.
AMD published a bulletin on August 6, AMD-SB-7061, titled “Safe RET Interrupt Vulnerability,” naming Zen 1 through Zen 4 processors as affected. Its summary says an attacker running code on an affected system “could inject an interrupt at a precise moment to disrupt Safe RET,” which “could potentially weaken that protection and may result in information disclosure.” AMD adds that the issue “appears to be associated with the Linux implementation of the Safe RET mitigation.”
The bulletin credits Trujillo and says the behavior was demonstrated on Zen 1 and Zen 2, with Zen 3 and Zen 4 suggested but not demonstrated. The paper reports AMD testing on Zen 2 and Zen 4 only. The section headed “Affected Products and Mitigation” lists processors and nothing else: no patch reference, no kernel version, and no CVE.
According to the paper the researchers shared with The Hacker News, Intel does not consider a mitigation necessary.
Neither AMD’s bulletin nor MIT’s announcement points to the kernel commit. Without a CVE or a named kernel release, an administrator has to know the commit subject to check whether a given machine carries the fix.
The kernel reports SRSO status at /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow, and the documentation defining that file’s values made no mention of interrupts when The Hacker News checked it on August 6.
The Hacker News has contacted AMD, Intel, and Arm for comment and will update this story with any response.
Each of these defenses sanitizes or isolates branch predictor state so an attacker’s earlier training cannot steer a kernel branch. Intel does it on kernel entry, with eIBRS and, depending on the processor, either a branch history buffer clearing loop or the BHI_DIS_S control. AMD does it immediately before each kernel return, with saferet.
All of them assume nothing hostile runs in between. Trujillo and Yan call the class TONTOU, for Time-of-Neutralization to Time-of-Use, after the TOCTOU races familiar from software. Interrupts break that assumption, because they fire almost anywhere and Linux lets any user schedule them with nanosecond granularity.
If interrupt handling can execute between neutralization and use, the interrupt-return path is part of the Spectre v2 defense even when the mitigation was designed around kernel entry or return.
On Zen 2 that window is two instructions, six bytes. The researchers widened their odds by evicting those bytes from L1 and L2 cache using a sibling hyperthread, slowing them down, and by picking the write syscall, which left them controlling two registers.
Interrupts landed inside the window 5% to 12% of the time, and around 2% with those registers under attacker control. Once inside, the handler itself became the training gadget, armed with Inception (CVE-2023-20569) to fill the return stack buffer with an attacker-chosen target. Inception is the 2023 AMD flaw saferet exists to stop.
Mispredictions turned up in kernel code on three of the four machines tested, at success rates of 0.75% on Zen 2, 0.22% on Intel Arrow Lake, and 0.037% on Cascade Lake Refresh. Zen 4 produced none in that test, and no end-to-end leak was demonstrated on Intel, where the attacker would also need a usable disclosure gadget already in the kernel.
The researchers do not treat that as a barrier. Mispredictions are “a necessary but not sufficient condition for a Spectre attack,” they told The Hacker News, and because prior work has already shown disclosure gadgets exist in kernels, “we believe an end-to-end attack is possible on Intel as well by combining our Interrupt Injection primitive with this work.”
Intel paid a discretionary bug bounty bonus but, per the paper, “does not consider mitigation to be required,” saying exploitability “depends on many factors” and that the technique is covered by existing guidance. The Hacker News reviewed that guidance, INTEL-SA-00598, in its current version last updated in May 2025, and found no mention of interrupts anywhere in it.
The pair presented the work at Black Hat USA today, and the paper is due at USENIX Security in Baltimore next week. As of August 6, the artifact repository named in it was not yet public.
