News & Commentary

A Two-Instruction Gap in AMD’s Spectre v2 Defense, Now Closed

MIT researchers found a two-instruction timing gap that let interrupts defeat AMD's Safe RET mitigation on Zen 1 through Zen 4. The kernel fix was already merged before disclosure; separately, Linux 7.2-rc6 untangles a Zen 5/Zen 6 ID mixup.

Saya3 minute readNews & Commentary

AMD's Linux-facing work this cycle runs in two directions: closing a real speculative-execution hole on chips already in people's machines, and quietly correcting how the kernel tells Zen 5 and Zen 6 apart. Neither needs a BIOS flash or new hardware, just a current kernel.

A two-instruction window let interrupts defeat Spectre v2 on Zen 1 through Zen 4

MIT CSAIL researchers Daniël Trujillo and Mengjia Yan found that Safe RET, AMD's mitigation for Speculative Return Stack Overflow, clears the CPU's branch-predictor state right before a protected kernel return executes, but leaves a brief gap before that cleared state is actually used. On a Zen 2 system that gap is two instructions, about six bytes. An unprivileged process can schedule a hardware interrupt with nanosecond precision, which Linux lets any user request, and keep retrying until one lands inside the window. When it does, the interrupt handler re-poisons the branch predictor Safe RET just cleared, and the Spectre v2 kernel-memory read comes back. Phoronix covered the disclosure as the attack, named TONTOU and tracked as CVE-2026-68480, went public.

Against a Zen 2 test system, the team read kernel memory at 5.47 bytes per second with 91.97% accuracy and pulled /etc/shadow password hashes in 5 of 10 runs, each taking about 18 minutes, Igor's Lab reports. AMD's security bulletin, AMD-SB-7061, published August 6, lists Zen 1 through Zen 4 as affected, though the live exploit was only demonstrated on Zen 1 and Zen 2; Zen 3 and Zen 4 are named as affected but not yet shown working in public, which is the narrower claim the evidence actually supports. AMD's own assessment treats this as a flaw in Safe RET's Linux implementation, not a defect in the Zen silicon, so no microcode or hardware revision is needed to fix it.

The kernel side was already handled before most people knew there was a problem. The commit, from AMD's David Kaplan working with kernel maintainer Borislav Petkov, landed in the stable trees on June 2, about two months ahead of the public writeup, and masks interrupts for the short duration the Safe RET sequence runs so nothing can land inside the gap. linuxcompatible.org's coverage lists the backport as shipping in the 6.18.43, 6.6.149, and 6.1.181 LTS point releases. Anyone running Zen 1 through Zen 4 on Linux can confirm the mitigation is active through the existing spec_rstack_overflow entry under sysfs; a kernel update covers it, with nothing to change in user space.

A smaller correction: some Zen 5 chips were mislabeled as Zen 6

Unrelated to the security fix, Linux 7.2-rc6 corrects a classification bug in the kernel's own AMD family ID table: CPU model IDs 0xd0 through 0xd7 in Family 1Ah had been tagged as Zen 6, when they actually belong to Zen 5. The corrected map puts Zen 5 back at 0xd0-0xd7 and reassigns Zen 6 to 0xc0-0xcf, 0xd8-0xef, 0x50-0x5f, and 0x80-0xaf. No retail Zen 6 desktop part exists yet to have been mislabeled in the field, so this is bookkeeping rather than a functional bug on shipping hardware, but it matters for anyone building or testing against early Zen 6 samples: the family ID is what the kernel uses to pick microcode handling and feature flags, and it needs to be right before more of that enablement work lands.

Sources: