On an AMD Zen 2 system, an unprivileged local program was able to leak kernel memory at 5.47 bytes per second with 91.97% accuracy — fast enough, the researchers say, to read /etc/shadow in half of ten attempts.
What the researchers found: INTERRUPT INJECTION and TONTOU
Researchers at MIT CSAIL, Daniël Trujillo and Mengjia Yan, named the technique INTERRUPT INJECTION and described a class of races they call TONTOU (Time-of-Neutralization to Time-of-Use). The core observation: defenses that sanitize or isolate branch predictor state — designed to block Spectre v2 style training — assume nothing hostile executes between the neutralization step and the subsequent use of the predictor. An interrupt can execute almost anywhere and, on Linux, users can schedule them with nanosecond granularity. That opens a window in which the branch predictor can be retrained after the mitigation has run.
How the proof-of-concept worked and measured success
On an AMD Zen 2 machine running Linux 6.14 with default Spectre v2 mitigations enabled, the exploit leaked arbitrary kernel memory at 5.47 bytes per second with 91.97% accuracy, and succeeded in locating and reading /etc/shadow in five of ten attempts. The attack needs no privileges — only local code execution — which places the risk on shared systems running affected processors.
The paper reports a narrow timing window on Zen 2 — two instructions, six bytes — in which an interrupt can land and let the interrupt handler serve as the training gadget. The researchers widened their odds by evicting those bytes from L1 and L2 cache (using a sibling hyperthread) and by choosing the write syscall, which left them controlling two registers. Interrupts landed inside the window 5% to 12% of the time, and around 2% when the attacker also controlled those registers. Once inside, the handler used Inception (CVE-2023-20569) to fill the return stack buffer with an attacker-chosen target, turning mispredictions into a disclosure primitive.
The cyber insurance questionnaire just landed. Now what?
SOC 2, HIPAA, insurance renewals - someone has to own security strategy. Nubivance provides fractional CISO leadership without the full-time salary.
Get a security leadCross-vendor tests and what worked where
The team tested multiple processors. Mispredictions appeared in kernel code on three of four machines: 0.75% on Zen 2, 0.22% on Intel Arrow Lake, and 0.037% on Cascade Lake Refresh. Zen 4 produced no mispredictions in that test, and the researchers did not demonstrate an end-to-end leak on Intel. The paper notes that on Intel an attacker would additionally need a usable disclosure gadget already present in the kernel, but the authors told The Hacker News they believe combining INTERRUPT INJECTION with prior work could enable an end-to-end Intel exploit.
AMD response, the Linux patch, and operational friction
The researchers disclosed the issue to AMD and Intel on February 5. AMD published a bulletin on August 6, AMD-SB-7061, titled "Safe RET Interrupt Vulnerability," naming Zen 1 through Zen 4 processors as affected and stating an attacker "could inject an interrupt at a precise moment to disrupt Safe RET," which "could potentially weaken that protection and may result in information disclosure." The bulletin credits Trujillo, says the behavior was demonstrated on Zen 1 and Zen 2 (with Zen 3 and Zen 4 suggested but not demonstrated), and lists affected processors but supplies no patch reference, no kernel version, and no CVE.
The Linux kernel contains a commit titled "x86/bugs: Make Safe-RET robust against interrupt injection," dated June 2 and authored by Borislav Petkov and co-developed with David Kaplan, both AMD engineers. The commit describes the same issue the researchers outlined: that injecting interrupts while Safe-RET runs "can neutralize the safe return sequence, potentially leading to data leakage through speculative execution." The kernel fix "fixes up register state as though the Safe-RET sequence had completed, and avoids executing a RET instruction after the interrupt returns" — one of the remediation routes proposed by the researchers. MIT says a kernel patch has shipped and will arrive via normal operating-system updates.
Operationally, the lack of a CVE, no named kernel release and no patch reference in AMD's bulletin creates friction for administrators: absent those markers, an operator must know the commit subject to check whether a machine carries the fix. The kernel reports SRSO status at /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow; when The Hacker News checked on August 6 the documentation defining that file's values made no mention of interrupts.
Intel's stance and disclosure handling
According to the paper shared with The Hacker News, Intel paid the researchers a discretionary bug bounty bonus but "does not consider mitigation to be required," saying exploitability "depends on many factors" and the technique is covered by existing guidance. The Hacker News reviewed Intel guidance, INTEL-SA-00598 (current version last updated May 2025), and found no mention of interrupts.
What this means for Linux maintainers and shared-system administrators
- Linux kernel maintainers and distro security teams: a kernel commit addressing Safe-RET exists (June 2); maintainers should ensure relevant kernels include the "x86/bugs: Make Safe-RET robust against interrupt injection" change and consider whether /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow documentation needs updating to reflect interrupt-based risks.
- Administrators of shared systems and cloud providers: because INTERRUPT INJECTION requires only local code execution, systems that allow unprivileged users or co-tenants to run code on the same hardware are the primary risk. Operators should track kernel updates and confirm that the Safe-RET robustness commit is present in their running kernels, since neither AMD's bulletin nor the vendor disclosures included a CVE or a kernel version string to make that check automatic.
The team presented the work at Black Hat USA on August 6, and the paper is scheduled for USENIX Security next week; as of August 6 the artifact repository named in the paper was not yet public. Intel, AMD and Arm were contacted for comment by The Hacker News.
