Greg Kroah-Hartman just shipped three Linux stable kernels, 6.18.43, 6.6.149, and 6.1.181, each patched against CVE-2026-68480. The update neutralizes a novel Spectre v2 bypass called "Interrupt Injection," which lets unprivileged users leak kernel memory by timing hardware interrupts inside AMD's Safe RET window. MIT researchers demonstrated reliable kernel reads on Zen 2, though Intel maintains existing mitigations remain sufficient. Apply the update today and verify protection status through the spec_rstack_overflow sysfs entry.

Linux Kernel LTS Stable Releases Patch New Spectre v2 Bypass Called "Interrupt Injection"

Greg Kroah-Hartman issued three more LTS kernel updates on August 6, 2026. Each containing a single patch addressing a novel Spectre v2 attack class discovered by MIT CSAIL researchers.

All three longterm kernel branches received the same security fix targeting what the researchers are calling "Interrupt Injection" (CVE-2026-68480). The technique exploits a timing window in AMD's Safe RET mechanism, the primary defense against Spectre v2 on AMD processors.

The Linux commit hit the stable trees on June 2, 2026, two months before public disclosure at Black Hat USA 2026. You can find the patches in Linux 6.18.43, 6.6.149, and 6.1.181.

Each release contains exactly two commits: the Linux tag itself plus the security patch. Not bad for a coordinated response.

How the Attack Actually Works

MIT CSAIL researchers Daniël Trujillo and Mengjia Yan discovered the technique they're naming INTERRUPT INJECTION, borrowing the TOCTOU pattern from software security. They're calling the broader attack class TONTOU (Time-of-Neutralization to Time-of-Use).

AMD processors defend against Spectre v2 using Safe RET, which sanitizes the branch predictor state right before each kernel return instruction. The mechanism assumes nothing hostile executes between sanitization and the subsequent use of the predictor. Specifically: no interrupts fire in that window.

An attacker can schedule a hardware interrupt with nanosecond precision to land inside that gap. On Zen 2, the window narrows to just 2 instructions or 6 bytes.

The interrupt handler becomes a training gadget for the branch predictor. Using the Inception vulnerability (CVE-2023-20569), it fills the return stack buffer with attacker-chosen targets. After the interrupt returns, the kernel proceeds with its original execution path — but now on mispredicted branches that leak data speculatively.

Here's where it gets practical. The researchers demonstrated a successful read of /etc/shadow on Zen 2 hardware at 5.47 bytes per second with 91.97% accuracy. Slow? Yes. Functional for targeted attacks against shared systems? Also yes.

Vendor Response Diverges

AMD published bulletin AMD-SB-7061, titled "Safe RET Interrupt Vulnerability," naming Zen 1 through Zen 4 processors as affected. The bulletin confirms the kernel patch and credits Trujillo for disclosure. Notably, the AMD bulletin doesn't reference a CVE number or specific kernel version, which could confuse system administrators trying to track affected systems.

Intel's response is notably less committal. The company considers mitigation unnecessary, stating exploitability "depends on many factors" and that the technique is covered by existing guidance (INTEL-SA-00598). Intel notes no mention of interrupts appears in their current document version, last updated May 2025.

That said, the researchers observed mispredictions on Intel Arrow Lake at a 0.22% rate. End-to-end leaks on Intel remain undemonstrated, though the researchers state such an attack is "possible" by combining Interrupt Injection with existing disclosure gadgets already present in kernels.

The kernel commit was dated June 2, 2026, well before the August 6 Black Hat presentation. Proactive defense, clearly.

Kernel Release Details

Linux kernel 6.18.43 released

Linux kernel version 6.18.43 is now available:

Full source: https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.18.43.tar.xz
Patch: https://cdn.kernel.org/pub/linux/kernel/v6.x/patch-6.18.43.xz
PGP Signature: https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.18.43.tar.sign

You can view the summary of the changes at the following URL:
https://git.kernel.org/stable/ds/v6.18.43/v6.18.42

The 6.18 base brought Slub percpu sheaves for improved slab allocation performance, a new swap table phase I backend, UDP receive optimization showing up to 50% improvement under DDoS conditions, and initial support for Google's PSP encryption for TCP.

Linux kernel 6.6.149 released

Linux kernel version 6.6.149 is now available:

Full source: https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.6.149.tar.xz
Patch: https://cdn.kernel.org/pub/linux/kernel/v6.x/patch-6.6.149.xz
PGP Signature: https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.6.149.tar.sign

You can view the summary of the changes at the following URL:
https://git.kernel.org/stable/ds/v6.6.149/v6.6.148

Linux 6.6 introduced the EEVDF scheduler replacing CFS, user-space shadow stacks for Intel CET support, and io_uring async DIO improvements showing up to 37% improvement in throughput/latency for low queue depth I/O.

Linux kernel 6.1.181 released

Linux kernel version 6.1.181 is now available:

Full source: https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.1.181.tar.xz
Patch: https://cdn.kernel.org/pub/linux/kernel/v6.x/patch-6.1.181.xz
PGP Signature: https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.1.181.tar.sign

You can view the summary of the changes at the following URL:
https://git.kernel.org/stable/ds/v6.1.181/v6.1.180

Linux 6.1 brought Rust language support to the kernel, multi-generational LRU for page reclaim, and the initial Map tree implementation replacing red-black trees in many subsystems.

Detection and Mitigation

Users can check mitigation status via:

/sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow

If you're running an AMD system, you should apply one of these patches now. The attack requires local code execution and isn't remote-exploitable, but the demonstrated success rate on Zen 2 makes this worth prioritizing — especially on shared systems, cloud instances, or CI servers.

For Intel systems, the risk appears lower based on current testing, though the researchers note end-to-end exploitation remains possible. Intel's position that existing guidance covers the technique will probably hold until someone demonstrates otherwise.