AMD Zen 6 makes Linux's SafeRET mitigation unnecessary

AMD's next generation of processors will let Linux stop applying one of its speculation defenses. A kernel patch titled "x86/bugs: Adapt SRSO mitigation to Zen6" landed in the tip tree on September 1, 2026. It matters because the chip now does in hardware what the kernel had been doing in software, and software mitigations run on every affected machine.

The patch was written by Borislav Petkov, a kernel engineer at AMD. He authored it on August 21, 2026 and committed it himself on September 1, 2026.

The attack being defended against

Modern processors guess what code will run next, which is called speculation. The guess keeps the chip busy instead of waiting. When the guess is wrong, the work is thrown away.

The problem is that the discarded work leaves traces. An attacker who can steer those guesses may get the processor to briefly touch data it should not, then read the traces to infer it. SRSO, short for Speculative Return Stack Overflow, is one such flaw. It targets the predictions the chip makes about where a function returns to. Phoronix reports that SRSO affected the Zen 1 through Zen 4 generations.

Linux answered SRSO with a software mitigation called SafeRET. That is the piece Zen 6 makes unnecessary.

What Zen 6 changes in hardware

The branch target buffer is a small cache where the processor keeps its guesses about where a jump in the code will land. If one program's entries can influence another's, those guesses become an attack surface.

Zen 6 separates them. "Zen6 has BTB protection which isolates the different contexts (user/kernel, guest/host) from one another," the commit message says. Phoronix calls the feature BTB CTX isolation, short for branch target buffer context isolation.

Two boundaries are covered by that description. One is between a normal program and the kernel. The other is between a virtual machine guest and the host running it.

What the patch actually does

The change is small and touches three files in the x86 code.

Item	Detail
Commit	"x86/bugs: Adapt SRSO mitigation to Zen6"
Author	Borislav Petkov (AMD)
Written	August 21, 2026
Committed to tip	September 1, 2026
Files changed	3
Target kernel	Linux 7.4, with 7.3 possible as a fix, per Phoronix

The three files are arch/x86/include/asm/cpufeatures.h, arch/x86/kernel/cpu/bugs.c and arch/x86/kernel/cpu/scattered.c. The kernel detects the new hardware behavior and then reports the situation through a new mitigation string.

What software still has to handle

The hardware protection does not cover everything, and the commit is explicit about the gap.

User-to-user and guest-to-guest attacks are still not handled by the chip. Those are cases where two programs at the same privilege level, or two virtual machines, attack each other. For those, the kernel keeps relying on the Spectre v2 mitigation settings to issue an IBPB on a context switch.

IBPB stands for Indirect Branch Predictor Barrier. It tells the processor to discard its accumulated branch guesses, which stops one workload's predictions from carrying into the next.

What this means for developers

Do not read this as "Zen 6 ends speculation mitigations." It removes one specific software fix at two specific boundaries, and it leaves same-privilege isolation to software. If you run untrusted code from different tenants on one host, your Spectre v2 configuration still matters as much as it did.

Check what your kernel reports rather than assuming. The patch adds a new mitigation string. Once you are on a kernel carrying this change, the state your machine is actually in shows up in the kernel's own reporting.

If you track mitigation overhead in your benchmarks, plan to re-baseline. Comparisons taken on Zen 4 with SafeRET active will not describe a Zen 6 machine without it, so old numbers should not be carried forward.

There is also no hardware to test against yet. These sources give no ship date for Zen 6 processors, so treat this as the kernel getting ready rather than a change you can measure this quarter. Kernel protection defaults move in both directions, and it is worth remembering the cost side: Microsoft is switching on Windows 11's memory integrity by default from October 13.