Safe RET Interrupt vulnerability exposes all AMD Zen 1 through Zen 4 processors — Linux kernel ships emergency fix

August 6, 2026, Phoronix, Safe RET Interrupt, AMD Zen 1–4. On August 6, 2026, a new speculative execution vulnerability was publicly disclosed: the Safe RET Interrupt flaw, affecting all AMD Zen 1 through Zen 4 processors. The issue lies in improper handling of the Speculative Return Stack Overflow (SRSO) mitigation within the Linux kernel — the very protection that was supposed to block this class of attack. A fix is already merged into the linux.git tree; distributions must package and deploy it in the coming hours.

The vulnerability was disclosed under a coordinated disclosure process. The fix landed in Linus Torvalds’ Git repository minutes before the public announcement, meaning maintainers had been notified ahead of time. No active exploit has been reported at the time of disclosure, but the nature of the vulnerability — a locally accessible speculative execution flaw — makes it exploitable by any user with shell access on an affected machine.

What the vulnerability does

The Safe RET Interrupt Vulnerability exploits an incorrect interaction between the Linux kernel’s SRSO (Speculative Return Stack Overflow) mechanism and interrupt handling on AMD processors. In summary:

• The Linux kernel applies an SRSO mitigation to protect the processor’s return stack against speculative overflow attacks.
• This mitigation uses special instructions (such as RAP OPERATION) to clear or reset the return stack during context transitions.
• The vulnerability triggers when an interrupt occurs during the execution of the SRSO mitigation code, leaving the return stack in an inconsistent state that an attacker can exploit to leak kernel memory data.

The result is a cross-privilege information leak: an unprivileged user process can, by carefully orchestrating interrupts and system calls, extract bytes of kernel memory. On a system where the kernel stores secrets (encryption keys, authentication tokens, neighboring process data), this leak can escalate into a local privilege escalation (LPE) if the attacker manages to reconstruct a critical memory address.

Affected scope

The scope is broad:

Zen 5 is not vulnerable because its microcode includes a revised version of SRSO handling that is not susceptible to the interrupt race condition. All previous generations — essentially every AMD processor in production since 2017 — are affected.

For cloud providers, the impact is significant. A malicious virtual machine with local root access on its instance can potentially leak data from the Linux hypervisor (KVM) if it runs on an AMD Zen 1–4 host. AWS, Google Cloud, Azure, and Oracle Cloud all offer AMD EPYC instances; patches are being deployed there as a priority.

The fix: one line, years of work

The fix itself is minimal. It modifies the SRSO handling routine in arch/x86/kernel/cpu/bugs.c to temporarily disable interrupts during the critical window of return stack manipulation. In other words, it makes the mitigation sequence atomic from an interrupt perspective — preventing the race condition that causes the leak.

The performance cost is negligible: the interrupt-disabled window lasts a few microseconds and only occurs at privileged context transitions (kernel entry/exit). Preliminary benchmarks on Phoronix show an impact below 0.3% on typical workloads (compilation, databases, encryption).

This fix is the result of years of work on speculative execution mitigations. Since Spectre and Meltdown in 2018, the Linux community has developed deep expertise in patching these architectural-level vulnerabilities, often with formidable complexity. The Safe RET Interrupt flaw shows that this work is not finished — and that each new mitigation can itself become an attack vector.

What to do now

Depending on your role, immediate actions differ:

• System administrator / SRE: apply the kernel patch as soon as it is available in your distribution. Critical priority for multi-tenant servers (cloud, shared hosting, VPS). High priority for workstations and single-tenant servers.
• Cloud provider / hoster: schedule a hypervisor reboot in the nearest maintenance window. If you use live patching (KernelCare, Livepatch), verify that the SRSO fix is included.
• Kernel developer: the commit is 2abd5287f083 in torvalds/linux.git. Backport to stable branches if you maintain a custom kernel.
• CISO / security lead: this vulnerability does not yet have a CVE at the time of writing, but a number will likely be assigned within 24 hours by MITRE. Integrate it into your vulnerability management process upon assignment. Track CISA KEV for potential addition.

Context: a rough patch for AMD

The Safe RET Interrupt flaw is part of a series of speculative execution vulnerabilities affecting AMD in recent months:

• January 2026: Inception v2 (CVE-2026-XXXXX), a variant of the original Inception attack, exploiting the AMD Zen 3/4 branch predictor.
• April 2026: SRSO v2, a regression in the original 2023 SRSO mitigation, quietly patched in linux-stable.
• August 2026: Safe RET Interrupt, the third SRSO flaw in three years.

This series suggests that the speculative execution attack surface on AMD is far from fully mapped. AMD security teams and Google Project Zero continue to actively explore these vectors — and each new discovery triggers an increasingly well-oiled patch cycle.

For CIOs managing AMD server fleets, the lesson is clear: kernel patching is no longer a monthly exercise; it is a weekly discipline. Maintenance windows must be shortened, and deployment processes must be automated (Ansible, Salt, live patching).

Verdict

The Safe RET Interrupt Vulnerability is a serious but manageable vulnerability. It affects a very broad range of AMD processors, but the fix is simple, low-cost in terms of performance, and already available in the upstream kernel.

If you run AMD servers in production, your only urgency is deployment velocity. Apply the patch within 48 hours for exposed servers (cloud, VPS, shared hosting) and within 7 days for internal servers. If your deployment process takes longer than 7 days, it is your process — not the vulnerability — that constitutes your primary security risk.

For future purchasing decisions, note that Zen 5 is not affected. If you are planning a fleet refresh in 2027, prefer EPYC 9005 (Zen 5) over 9004 (Zen 4) — the speculative security delta adds to the performance delta to justify the investment.

References

• Phoronix — Linux Patched For Safe RET Interrupt Vulnerability, August 6, 2026
• Commit torvalds/linux.git: 2abd5287f083
• Linux kernel documentation — Speculative Return Stack Overflow