CPU Interrupts Bypass Spectre Defenses

A new research finding demonstrates that unprivileged code can bypass hardware-level security protections by manipulating the timing of processor interrupts. The method, identified by MIT CSAIL researchers Daniël Trujillo and Mengjia Yan, targets the brief window between a processor's branch predictor sanitization and the subsequent use of that predictor by the kernel.

The Mechanics of INTERRUPT INJECTION

The researchers, who named the technique INTERRUPT INJECTION, discovered that by timing a hardware interrupt to land precisely within the sanitization gap, an attacker can re-poison the branch predictor after the system's defensive measures have already executed. This process effectively neutralizes protections designed to stop Spectre v2 style attacks.

By leveraging this technique, the researchers demonstrated the ability to leak arbitrary kernel memory on an AMD Zen 2 system running Linux 6.14. The exploit was successful even with all default Spectre v2 mitigations enabled, allowing the researchers to locate and read sensitive system files, including /etc/shadow, which contains password hashes.

Quantifying the Vulnerability

• Data leakage rate: 5.47 bytes per second
• Leakage accuracy: 91.97%
• Success rate for reading /etc/shadow: five of ten attempts
• Window of vulnerability on Zen 2: two instructions, six bytes
• Misprediction success rate on Zen 2: 0.75%
• Misprediction success rate on Intel Arrow Lake: 0.22%
• Misprediction success rate on Cascade Lake Refresh: 0.037%

Kernel-Level Remediation

The Linux kernel has received a patch to address the vulnerability, which is documented in a commit titled "x86/bugs: Make Safe-RET robust against interrupt injection." Dated June 2, the fix was authored by AMD engineers Borislav Petkov and David Kaplan. The patch modifies the register state to ensure that the Safe-RET sequence is treated as complete, preventing the execution of a RET instruction following an interrupt return.

AMD issued bulletin AMD-SB-7061 on August 6, acknowledging that the issue affects Zen 1 through Zen 4 processors. The company stated that the vulnerability appears associated with the specific Linux implementation of the Safe-RET mitigation. While the researchers demonstrated the attack on Zen 1 and Zen 2, the bulletin suggests that Zen 3 and Zen 4 are also potentially affected.

The TONTOU Class of Flaws

Trujillo and Yan categorize this attack as TONTOU, standing for Time-of-Neutralization to Time-of-Use. This reflects a hardware-level parallel to traditional software TOCTOU races. Because Linux allows user-space processes to schedule interrupts with nanosecond granularity, the researchers found that these interrupts can reliably fire during the critical window between the neutralization of branch predictor state and the kernel's use of that state.

Intel's Stance on Mitigation

Intel has taken a different position regarding the necessity of a fix. According to the research paper, the company does not consider a mitigation to be required for its processors. While Intel provided a discretionary bug bounty bonus to the researchers, the company maintains that the technique is covered by existing guidance.

Mispredictions are a necessary but not sufficient condition for a Spectre attack, 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.

— Daniël Trujillo and Mengjia Yan, MIT CSAIL researchers

Implications for System Security

The lack of a formal CVE identifier or specific kernel version reference for this vulnerability presents a challenge for administrators attempting to verify their patch status. As the kernel's vulnerability reporting file, documentation defining that file's values, does not currently reference interrupt-based attacks, organizations may find it difficult to determine if their specific systems have successfully integrated the necessary commit. This ambiguity suggests that reliance on automated security reporting may be insufficient to confirm protection against this specific class of hardware-level exploitation.