Security researchers have uncovered a new way to interfere with Spectre v2 protections on affected Intel and AMD CPUs. The core idea is interrupt injection: an unprivileged Linux program times a hardware interrupt so it lands in the tiny gap between when the processor neutralizes branch-predictor state and when the kernel actually uses it—effectively re-poisoning the predictor after the defense has already run.
Because interrupts can fire unpredictably and Linux allows users to schedule them with high timing resolution, this approach challenges a common assumption in several branch-mitigation designs: that nothing hostile executes between “neutralization” and “use.”
What is interrupt injection?
In Spectre v2 defenses, the system tries to prevent earlier attacker-controlled training from steering kernel branches. Many mitigations do so by sanitizing branch-predictor state at specific moments—such as when entering the kernel or right before returning back to user space.
The new technique reframes that boundary. The researchers argue that the relevant window isn’t limited to the original sanitization point. Instead, if an interrupt handler can execute inside the time between the predictor is cleared and the kernel consumes that predictor state, then the interrupt path becomes part of the attack surface.
They call this class of timing problem TONTOU—Time-of-Neutralization to Time-of-Use—by analogy to the familiar TOCTOU pattern in software race conditions.
How the attack works on Linux
The researchers’ proof of concept runs from a local, unprivileged Linux process. It focuses on creating a narrow timing opportunity, then landing an interrupt precisely inside that gap.
On AMD Zen 2, the described window is extremely small—two instructions, six bytes. To improve the chances, the researchers expanded their odds by evicting those instruction bytes from the CPU caches. They also relied on particular register control created by choosing a write syscall, which left the attacker controlling two registers.
In their measurements, interrupts landed in the target window between 5% and 12% of the time, and closer to 2% with the attacker-controlled register setup. Once an interrupt hits the window, the interrupt handler itself can act as the training gadget to refill the return stack buffer with an attacker-chosen target.
The paper references a component named Inception (CVE-2023-20569). Inception is associated with the saferet mechanism that exists to stop similar return-stack issues, and it becomes a practical tool for shaping the prediction state after the mitigation has run.
Reported impact: memory disclosure on AMD
On an AMD Zen 2 machine running Linux 6.14 with default Spectre v2 mitigations enabled, the researchers reported a kernel memory leakage rate of about 5.47 bytes per second at 91.97% accuracy.
They further demonstrate that this capability can be sufficient to locate and read /etc/shadow, the file that stores system password hashes. In their experiment, the file was successfully read in five out of ten attempts.
Since the exploit requires local code execution but not elevated privileges, the risk is primarily about exposure on shared systems where an attacker can run unprivileged code on an affected processor.
Which CPUs are affected?
AMD published a security bulletin describing the issue under the title “Safe RET Interrupt Vulnerability” and lists affected products spanning Zen 1 through Zen 4. The bulletin suggests an attacker could inject an interrupt at a precise moment to disrupt the “Safe RET” protection, potentially weakening it and leading to information disclosure.
The bulletin states that the issue appears associated with the Linux implementation of the Safe RET mitigation. It also credits the researchers and indicates behavior was demonstrated on Zen 1 and Zen 2, while Zen 3 and Zen 4 are suggested but not demonstrated in the cited work.
At the same time, the research paper indicates testing on Zen 2 and Zen 4 only, highlighting differences between what was demonstrated and what was assessed across the product line.
What about Intel? No end-to-end proof in the tests
The researchers describe different mitigation strategies on Intel as well, including how sanitization may occur during kernel entry and how other controls can manage branch history buffer behavior depending on the processor generation.
While the paper reports mispredictions in kernel code on some Intel systems tested—at success rates of about 0.22% on an Intel Arrow Lake machine and 0.037% on a Cascade Lake Refresh system—it does not show an end-to-end leak on Intel in that setup.
The paper’s authors note that misprediction alone is not enough; they emphasize that disclosure gadgets already exist in kernels based on earlier research. Based on that, they believe end-to-end attacks are possible on Intel too by combining the interrupt injection primitive with previously identified gadget work.
Why defenders may have trouble confirming patch status
In the responsible disclosure timeline, the researchers informed AMD and Intel on February 5. According to reporting, AMD plans a kernel patch, while MIT states that a kernel patch has been shipped and is expected to arrive through standard operating system updates.
However, the practical problem for administrators is verification. The AMD bulletin does not provide a patch version, a kernel commit reference, or a CVE identifier. It also lists processors in the “Affected Products and Mitigation” section without concrete upgrade markers. As a result, there’s no simple checklist for determining whether a given machine already includes the relevant fix.
Additionally, the kernel’s reporting of Spectre-related status—exposed in a sysfs vulnerability path under /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow—may not reflect interrupt-related details. Documentation that defines those values did not mention interrupts when checked during the reported investigation.
What mitigations are being proposed?
The key proposed mitigation concept is to prevent the return stack buffer or related predictor state from being left in a tainted condition after an interrupt handler runs. The researchers describe a fix direction that adds a second neutralization step on the way out of an interrupt.
On Intel systems, this can mean ensuring the return stack buffer is updated before iret, or—on newer Intel parts—issuing an appropriate IBHF operation at the right location. The alternative approach of blocking interrupts during the entire narrow window was discussed, but the work does not quantify the performance cost of that option.
In other words, rather than relying solely on a single sanitization moment, the mitigation strengthens the process by reapplying protection around the interrupt return path.
Intel’s stance and ongoing guidance
According to the researchers, Intel does not consider a mitigation necessary, and this stance was reportedly echoed in the review of existing guidance. The cited guidance document last updated in May 2025 was checked for mention of interrupt behavior, and none was found.
Intel’s perspective, as described, is that exploitability depends on multiple factors, and that the technique is covered by existing guidance. Meanwhile, the researchers argue that the interrupt-return path can effectively fall within the Spectre v2 defense boundary even when mitigations were originally designed around kernel entry or return points.
Timeline and disclosure status
The work was presented at Black Hat USA, and the paper is scheduled for USENIX Security the following week. As of the reported date, the public artifact repository referenced in the paper was not yet available.
AMD has published the bulletin (AMD-SB-7061) and plans to deliver the fix via kernel-level changes. For administrators, the main challenge remains mapping that advisory information to a specific, verifiable patch state—especially given the lack of a CVE and a clearly labeled patch version in the bulletin.
Bottom line for system owners
Interrupt injection shows how attackers can exploit timing assumptions in modern speculative execution defenses. Even when Spectre v2 mitigations are enabled by default, a narrow interrupt timing window may still allow attacker-controlled prediction state to influence kernel behavior.
If you run Linux on systems with affected AMD or Intel CPUs, the most actionable step is to monitor vendor guidance and update through normal OS/security channels as patches become available. Until patch granularity and verification become clearer, confirming mitigation status may require careful tracking of kernel versions and distro updates rather than relying solely on vulnerability summaries.
Source: https://thehackernews.com/2026/08/new-interrupt-injection-attack-can.html
