CVE-2026-68480: the Safe-RET mitigation has a bug, stable kernels are out

The AMD SRSO saga continues its grand tradition of “the mitigation is also broken.”

Five stable kernel releases dropped this week: 6.12.102, 6.6.150, 6.1.182, 5.15.215, and 5.10.264. They all carry one meaningful fix: CVE-2026-68480, a hole in the Safe-RET mitigation that lets a local attacker inject interrupts at exactly the wrong moment and leak kernel memory through speculative execution. CVSS 8.8. High severity. Affects every distro shipping with CONFIG_MITIGATION_SRSO enabled, which is all of them.

Patch your kernels. Then read the rest of this if you want to understand why this keeps happening.

What SRSO is and why Safe-RET exists

SRSO is Speculative Return Stack Overflow, an AMD-specific Spectre variant. The short version: AMD processors use a Return Stack Buffer (RSB) to predict return addresses. An attacker who can fill that buffer with crafted entries can steer the processor’s speculative execution toward attacker-controlled code paths, then read data that leaks out before the processor notices it was wrong and rolls back the architectural state. The CPU corrects itself. The cache state stays dirty. Classic.

Safe-RET was AMD and the kernel’s answer to this. Instead of returning through the RSB directly, Safe-RET pads the return path so the buffer can’t be meaningfully trained. The processor’s branch predictor is still lying to it, but the lie goes nowhere useful. Or it was supposed to.

The interrupt injection problem

CVE-2026-68480 is a race condition in the mitigation itself. Safe-RET is a sequence: it does specific work in a specific order, and the CPU’s speculative execution is only safe because the sequence runs to completion. If an interrupt arrives mid-sequence, the safe return sequence is “neutralized” before it finishes. The processor picks up where it left off after interrupt handling, but the preconditions Safe-RET established are gone. The RSB is in a half-trained state. Speculation goes somewhere it shouldn’t. Data leaks.

The attacker’s requirement is being able to inject interrupts. That sounds hard but local privilege is enough. If you’re running untrusted code on bare metal with any kind of shared compute, or if a compromised process in your system can trigger timer-based interrupts at a predictable rate, you have the primitive.

The fix

The patch introduces handle_interrupted_saferet(), a routine that runs when the kernel detects a return from interrupt handler that interrupted a Safe-RET sequence. It adjusts register state to emulate a successful Safe-RET completion, so the processor continues as if the sequence ran cleanly. An LFENCE serializes execution afterward to prevent any residual speculative leakage.

It also adds a path that avoids executing a RET instruction directly after returning from the interrupt handler in this case, plugging the specific path where speculation was escaping.

The affected files are: arch/x86/entry/entry_64.S, arch/x86/include/asm/nospec-branch.h, arch/x86/kernel/cpu/bugs.c, and arch/x86/lib/retpoline.S. If you’ve spent any time in the kernel’s speculative execution mitigation code, this will look familiar. It’s the same files that have been accreting patches since 2018.

What this means in practice

If you’re running AMD hardware, any kernel that shipped CONFIG_MITIGATION_SRSO (which is everything) is affected until you apply this fix. The attack requires local access and the ability to influence interrupt timing, so it’s not a remote code execution issue. But a process that can read kernel memory is a process that can pull credentials, keys, and anything else the kernel is holding. In a cloud context or any environment where untrusted workloads run alongside trusted ones, this is a meaningful exposure.

Run uname -r. If you’re on a kernel older than 6.12.102, 6.6.150, 6.1.182, 5.15.215, or 5.10.264 and your hardware is AMD, update now. Your distro’s stable packages probably have these by end of week; check your vendor’s errata if you need them sooner.

The actual observation here

Rod’s not surprised by this. He’s tired of it, which is different.

The SRSO mitigation went into the kernel in 2023. It took three years for someone to find a reliable interrupt-injection window inside the mitigation sequence itself. That three-year window is not a reassuring number. It means the attack surface of speculative-execution mitigations is large enough that competent people missed this for years of production use.

This is the same pattern as Spectre/Meltdown (2018), Retbleed (2022), SRSO itself (2023), and now CVE-2026-68480. Each mitigation creates new code in the kernel’s most security-sensitive paths, and that code is itself a target. The mitigations are correct. The architecture that requires them is not.

The problem is not the kernel developers. They are doing hard, careful work under constraints that no amount of review eliminates. The prctl hardening work gives you per-process mitigation control, which matters when you’re trying to quantify your exposure. The mseal() work is adding another layer of hardened memory semantics. These are good tools. They keep getting needed because the hardware keeps creating the holes.

AMD chips are not uniquely bad. Intel has Spectre, MDS, Downfall, and a catalog of its own. The x86 architecture in general carries twenty-plus years of speculative execution features that were designed for performance and not for adversarial environments. That bill keeps coming due. Patch your kernels, audit your threat model, and stop running untrusted code on bare metal if you have any better option at all.