TONTOU Attack (AMD-SB-7061): MIT Breaks Every Spectre v2 Mitigation on Linux — Unprivileged Code Steals Root Password Hashes in 18 Minutes

You patched Spectre. You enabled Safe RET. Your security checklist reads Spectre v2 — Mitigated. But on 6 August 2026, researchers from MIT’s Computer Science and Artificial Intelligence Laboratory (CSAIL) stood at Black Hat USA and proved that mitigation has a race condition — and on AMD Zen processors running Linux, it can be defeated by any unprivileged user account on the system.

The technique is called TONTOU (Time-of-Neutralization to Time-of-Use). By injecting a hardware timer interrupt at a precisely-timed nanosecond window, an ordinary user process — no root, no exploit, no rootkit — can re-poison the CPU’s branch predictor after Safe RET flushes it, then read arbitrary kernel memory through a timing side channel. In testing on a fully-patched Ubuntu workstation, the MIT team extracted the /etc/shadow hashed root password file in an average of 18 minutes.

AMD has issued Security Bulletin AMD-SB-7061 covering Zen 1 through Zen 4 processors. Linux kernel patches shipped in June. The question is not whether the fix exists — it is whether your servers are running it.

Spectre Never Really Left — What TONTOU Means

Spectre v2 (CVE-2017-5715), first disclosed in January 2018, exploits speculative execution — the CPU habit of predicting and pre-computing future code paths to maximise performance. Attackers who manipulate the branch predictor cause the CPU to speculatively access privileged memory; that data leaks through a timing side channel before the processor discards its illegal work.

The industry responded with neutralization-based mitigations: techniques that flush or sanitise branch predictor state at the user-to-kernel boundary. AMD’s approach is Safe RET, which protects against Speculative Return Stack Overflow (SRSO). Intel uses eIBRS (Enhanced Indirect Branch Restricted Speculation). Both work by ensuring the return predictor is clean before the kernel executes sensitive code.

TONTOU identifies the gap neither mitigation closed: the nanosecond window between when Safe RET neutralises the branch predictor and when the kernel actually uses it. That window is real, measurable, and — as MIT just proved — exploitable. AMD’s bulletin AMD-SB-7061 acknowledges the issue is “associated with the Linux implementation of the Safe RET mitigation,” not the processor hardware itself. That framing matters: the fix lives in the kernel, and you need to update it.

How the Interrupt Injection Attack Works — Step by Step

The attack is elegant in its simplicity. Linux allows unprivileged programs to schedule hardware timer interrupts. TONTOU times that interrupt to land in the nanosecond gap after Safe RET flushes the branch predictor but before the kernel executes its critical RET instruction. The attack unfolds in four stages:

1. Neutralization: AMD’s Safe RET executes, flushing branch predictor state at the kernel entry point — exactly as designed.
2. Interrupt Injection: The attacker’s unprivileged process fires a timer interrupt timed to land inside the TONTOU window — after the flush, before the RET.
3. Poisoning: From within the interrupt handler, the attacker writes malicious branch predictor targets back into the CPU’s predictor state.
4. Exploitation: The kernel resumes and executes its RET with a now-poisoned predictor, speculatively jumping to attacker-controlled code — leaking memory through a timing side channel.

The result is a working exploit that requires no special privileges, no kernel vulnerability, and no modification to the target system. It runs on a completely stock Ubuntu installation with all security updates applied. On AMD Zen 2 hardware, the researchers achieved a branch misprediction rate of 0.75% — enough to sustain a reliable, steady-state kernel memory leak.

Notably, Intel’s misprediction rates were substantially lower (0.22% on Arrow Lake; 0.037% on Cascade Lake Refresh), and Intel has stated that its eIBRS mitigation is sufficient — no new patch has been issued for Intel processors. The confirmed threat is primarily an AMD Linux concern.

The Proof: Extracting Root Password Hashes in 18 Minutes

The MIT CSAIL team ran quantified experiments on a standard AMD Zen 2 workstation (Linux 6.14.0-37-generic, 16 GB RAM) — representative of the AMD EPYC Rome–based servers and cloud instances widely deployed across enterprise India and globally.

Processor	Misprediction Rate	End-to-End Exploit	Vendor Status
AMD Zen 2 (EPYC Rome, Ryzen 3000)	0.75%	Demonstrated — /etc/shadow in ~18 min	AMD-SB-7061; Linux patch issued
AMD Zen 4 (EPYC Genoa, Ryzen 7000)	Not published	Not demonstrated (bulletin covers Zen 1–4)	AMD-SB-7061; Linux patch issued
Intel Arrow Lake	0.22%	Not demonstrated	eIBRS guidance sufficient; no patch
Intel Cascade Lake Refresh	0.037%	Not demonstrated	eIBRS guidance sufficient; no patch

Leak rate: 5.47 bytes per second at 91.97% accuracy. In 5 of 10 test runs, the researchers successfully extracted the complete /etc/shadow file. Once an attacker holds hashed passwords, offline cracking with modern GPU tooling — hashcat on an RTX 4090, or a cloud-based cracking cluster — turns those hashes into plaintext in hours, not days, for weak or moderately complex passwords.

Who Is Affected — And What the Threat Model Really Looks Like

AMD Security Bulletin AMD-SB-7061 explicitly covers AMD Zen 1, Zen 2, Zen 3, and Zen 4 processors. In practical terms, this means:

• EPYC Rome (7002), Milan (7003), Genoa (9004), and Turin (9005) server CPUs
• Ryzen Pro workstations
• AMD-based cloud instances: AWS C5a, M6a, R6a, T3a; Azure Dav4/Eav4; Google Cloud N2D

The critical qualifier: TONTOU requires local code execution. This is not a remote exploit. An attacker needs an existing foothold — a compromised application, a malicious container, a shared Kubernetes pod, or a developer account obtained through phishing or credential stuffing. In SOC kill-chain terms, TONTOU appears between initial access and privilege escalation.

In multi-tenant environments — shared Kubernetes clusters, co-located build servers, VDI platforms — a workload compromise in one tenant can become a kernel credential dump affecting every tenant on the host. If your hypervisor itself runs on an AMD Linux kernel, the risk extends upward: a compromised guest VM could potentially escalate to the hypervisor’s kernel memory, a trajectory similar to the cross-VM escalation risks we examined last week with CVE-2026-57092.

The Fix Exists — Verify That Your Servers Are Running It

A Linux kernel patch for TONTOU was committed on 2 June 2026 — two months before today’s Black Hat disclosure. AMD’s David Kaplan and SUSE’s Borislav Petkov co-authored the fix, titled “x86/bugs: Make Safe-RET robust against interrupt injection.” It ships in:

• Linux 6.18.43 (mainline stable)
• Linux 6.6.149 (LTS)
• Linux 6.1.181 (LTS)

Most enterprise Linux distributions — RHEL 9, SUSE Linux Enterprise 15, Ubuntu 22.04/24.04 LTS — backport these security fixes through normal update channels. Running apt upgrade && reboot or dnf update && reboot may already have delivered the fix without fanfare. To verify:

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

If the output reads Safe RET (hardened) or equivalent, the patch is applied. If it reads simply Safe RET without the hardening qualifier, your system needs the updated kernel. Intel-based systems show a different mitigation status and are not known to be affected by this specific technique.

What You Should Do Right Now — Sanjay Seth’s Expert Perspective

In three decades of building enterprise security infrastructure in Delhi NCR and across India, I have seen this pattern repeat: hardware-level disclosures land without a CVE, without a CISA deadline, and without the urgency their impact deserves. Network teams chase firewall CVEs and endpoint EDR alerts while the CPU under their Linux server quietly bleeds kernel memory to an unprivileged process. That invisibility is exactly what makes TONTOU dangerous.

Here is the action plan I am recommending to every client running AMD-based Linux infrastructure:

• Patch tonight — reboot required. Run apt upgrade or dnf update on all AMD Linux hosts and reboot to load the new kernel. The patch does nothing until you are actually running the updated kernel. Prioritise: Kubernetes worker nodes, shared build servers, VDI hosts, and any bare-metal AMD cloud instances.
• Audit cloud instance families. Identify all AWS C5a/M6a, Azure Dav4, and GCP N2D workloads. Verify the underlying OS image’s kernel version. Update AMIs and VM images and roll instances. For managed Kubernetes, check the node pool kernel version against your cloud provider’s update documentation.
• Apply zero-trust to local access. TONTOU’s threat model begins with local code execution — meaning it lives in the space between initial compromise and credential dumping. As Midnight Blizzard’s CaptiveCrunch campaign demonstrated, once an attacker has any foothold inside your environment, lateral movement and escalation paths multiply rapidly. Restricting what code can run on privileged systems — through tight RBAC, least-privilege service accounts, and network-segmented workloads — substantially narrows TONTOU’s attack surface.
• Harden container runtimes. Deploy seccomp profiles, AppArmor policies, or gVisor sandboxing for untrusted container workloads. These controls significantly raise the difficulty of exploiting TONTOU from a container environment by limiting syscall access to interrupt scheduling mechanisms.
• Monitor and add to CMDB. Integrate spec_rstack_overflow status into your system compliance tooling. Treat Spectre-class mitigation status with the same urgency as CVE-driven patch compliance. It should appear in your NOC/SOC dashboards alongside CIS Benchmark results.

Frequently Asked Questions

Does TONTOU affect Windows servers running AMD processors?

No. TONTOU specifically exploits Linux’s Safe RET implementation. AMD’s bulletin explicitly states the issue is “associated with the Linux implementation of the Safe RET mitigation” — not AMD hardware itself. Windows uses different Spectre v2 mitigations (Retpoline, KVA Shadow, IBA) and Microsoft has not issued a TONTOU-specific advisory. AMD Zen systems running Windows are not known to be affected by this technique.

Is TONTOU being exploited by real threat actors right now?

No confirmed in-the-wild exploitation exists as of 7 August 2026. The attack was publicly demonstrated by the MIT CSAIL team for the first time at Black Hat USA on 6 August. However, the researchers released sufficient methodology — and the full paper is accepted at USENIX Security 2026 — that motivated threat actors have the information they need to begin building tooling. Based on 2026 exploitation timelines, where weaponisation of newly disclosed research often occurs within days to weeks, treat this as a 30-day patch window.

Can our FortiGate, IDS, or SIEM detect a TONTOU attack?

Network-based controls — FortiGate firewalls, IDS/IPS, perimeter NDR — will not see TONTOU at all. It generates no anomalous network traffic whatsoever. Detection requires host-based telemetry: auditd rules monitoring for unusual interrupt scheduling syscalls, eBPF-based kernel observability, or runtime security tools like Falco or Tetragon configured to flag abnormal process-to-kernel timing patterns. If you don’t have host-level kernel observability on your AMD Linux servers today, this is the moment to add it.

How is TONTOU different from the original 2018 Spectre?

Classic Spectre v2 poisons the branch predictor before the kernel mitigation fires. Safe RET was engineered specifically to stop this by flushing predictor state at the user-kernel boundary. TONTOU adds one more step: it re-poisons the predictor after the flush, by injecting an interrupt in the nanosecond window between the flush and the kernel’s RET instruction. It is, technically, a race condition in the mitigation — not around it.

---

TONTOU is a reminder that cybersecurity is not a problem you solve once. Spectre was “fixed” eight years ago. In 2026, MIT researchers proved the fix has a nanosecond race condition that bleeds root password hashes from a fully-patched server. The organisations that weather these disclosures best are the ones with fast patch cycles, verified kernel compliance, and layered zero-trust controls — not the ones waiting for a CISA deadline to act.

If your organisation runs AMD-based Linux infrastructure and you want a professional review of your server hardening posture, kernel patch compliance, or zero-trust network architecture, contact us for a security assessment. P J Networks has been building and auditing enterprise security infrastructure in Delhi NCR and across India for over 30 years. The conversation starts free — discovering a gap after an incident does not.