# TONTOU: Researchers Crack Open Spectre v2 Defenses, Pull Linux Password Hashes from Kernel Memory


## The Threat


Eight years after Spectre upended the CPU security model, researchers at MIT CSAIL have found a way to slip past the mitigations vendors spent years building to stop Branch Target Injection attacks. The technique, called TONTOU — Time-of-Neutralization to Time-of-Use — exploits a race condition that exists inside the very defenses meant to make Spectre v2 safe.


Spectre v2 works by manipulating a processor's indirect branch predictor, tricking the CPU into speculatively executing instructions at an attacker-chosen location and then leaking whatever data those speculative instructions touch. Intel and AMD responded with neutralization-based mitigations: Intel's eIBRS and AMD's Safe RET both sanitize or isolate the branch predictor so that attacker-poisoned entries can't influence privileged execution. The assumption baked into both defenses is that once the predictor state is cleaned, an attacker has no viable path to re-corrupt it before it gets used.


That assumption is wrong. PhD candidate Daniël Trujillo and associate professor Mengjia Yan demonstrate that a gap — measurable in CPU time — exists between neutralization and use. By scheduling timer interrupts to fire precisely inside that window, an unprivileged user process can re-poison the branch predictor state *after* the hardware cleanup runs and *before* the kernel uses the now-dirty predictor. The result: an attacker who can execute arbitrary unprivileged code on a Linux machine can read arbitrary kernel memory — including the contents of /etc/shadow, the file that stores hashed user passwords.


## Severity and Impact


| Field | Detail |

|---|---|

| CVE | Not yet assigned (disclosure August 2026) |

| CVSS Score | Not yet formally scored; researcher-assessed as high-impact |

| Attack Vector | Local |

| Attack Complexity | High |

| Privileges Required | Low (unprivileged code execution on target) |

| User Interaction | None |

| Scope | Changed (user-space to kernel-space information disclosure) |

| CWE | CWE-203 (Observable Discrepancy), CWE-362 (Race Condition) |

| Leak Rate | 5.47 bytes/sec at 91.97% accuracy on AMD Zen 2 |

| Affected Mitigations Bypassed | Intel eIBRS, AMD Safe RET |


## Affected Products


Intel processors:

  • All processors relying on Enhanced Indirect Branch Restricted Speculation (eIBRS) as the primary Spectre v2 mitigation

    • AMD processors:

  • AMD Zen 2 confirmed in lab testing
  • All processors relying on Safe RET as the primary Spectre v2 mitigation

    • Operating Systems:

  • Linux (tested on kernel 6.14.0-37-generic)
  • Other operating systems using neutralization-based Spectre v2 mitigations are likely affected; extent is under investigation

    • Not affected:

  • Systems using retpoline-only mitigations (though retpoline carries its own trade-offs)
  • Architectures that do not implement speculative indirect branch prediction

    • ## Mitigations


    At time of publication, no vendor patch exists that closes the TONTOU window. Organizations should:


  • Monitor for vendor microcode and kernel updates. Intel and AMD have been notified. Linux kernel maintainers will need to issue patches addressing the post-neutralization poisoning primitive once a remediation strategy is agreed upon.
  • Restrict local code execution aggressively. The attack requires the ability to run arbitrary unprivileged code on the target machine. Hardening this requirement — through strict process isolation, seccomp profiles, and container security policies — raises the bar significantly.
  • Treat shared compute environments as elevated risk. Cloud VMs, multi-tenant containers, and any environment where co-resident workloads from different trust boundaries share physical CPUs are the most exposed scenarios. Consider dedicated hosts for workloads that process sensitive credentials or secrets.
  • Enable kernel lockdown mode where feasible. While it does not directly block TONTOU, it limits ancillary primitives that enable interrupt injection.
  • Audit access to /etc/shadow and credential stores. Until a fix lands, assume that privilege separation at the OS level is insufficient on affected hardware if an attacker can run code locally.
  • Watch the Linux kernel mailing list. Kernel mitigations for speculative execution vulnerabilities historically move fast once a working exploit is published.

    • ## References


  • [BleepingComputer — Original Report by Ionut Ilascu](https://www.bleepingcomputer.com/)
  • [MIT CSAIL Research Group — Mengjia Yan](https://www.csail.mit.edu/)
  • [Linux Kernel Spectre/Meltdown Documentation](https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/)
  • [Intel eIBRS Documentation](https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/)
  • [AMD Spectre Guidance](https://www.amd.com/en/resources/product-security/bulletin/amd-sb-1030.html)

    • ---


    ## HackWire Analysis


    The security industry made a tacit bet after the Spectre/Meltdown disclosures of 2018: hardware mitigations, despite their performance costs, would eventually close off the speculative execution attack surface. TONTOU is the clearest evidence yet that bet was premature.


    What makes this finding particularly uncomfortable is the mechanism. Interrupt injection is not exotic. Timer interrupts are a foundational part of how operating systems multitask. The fact that an unprivileged process can schedule hardware interrupts that fire during kernel execution — and that this primitive was not considered in the threat model for eIBRS and Safe RET — is a design-level oversight, not an edge case. The neutralization-based mitigations were engineered around a race condition model that assumed the post-neutralization window was inaccessible to attackers. That assumption collapsed under a graduate student's scrutiny.


    The /etc/shadow extraction is the detail that will drive urgency here. A 5.47 bytes/sec leak sounds slow until you realize that shadow file entries are compact — a few hundred bytes per user. In multi-tenant cloud environments, container escape or a compromised co-resident workload can turn that leak rate into a credential dump within minutes. Cloud providers that run noisy-neighbor workloads on shared physical CPUs should treat this as an active threat, not a theoretical one.


    The longer pattern is damning. Every generation of hardware mitigation for Spectre has eventually yielded to a bypass — Spectre-v2, Retbleed, BHI, and now TONTOU. Each bypass required a new kernel patch, new microcode, and often a new performance regression. CPU vendors need to acknowledge that sanitization-based defenses are fundamentally fighting a time-of-check/time-of-use problem in silicon, and that problem does not get easier as hardware grows more complex. At some point, the industry needs an architectural answer, not a longer list of post-hoc neutralizations.


    For defenders right now: restrict local code execution like your passwords depend on it, because they do.


    — HackWire Editorial


    ---


    ## Related Coverage


  • Read more in our [Vulnerabilities](https://www.hackwire.news/category/vulnerabilities) coverage
  • Cross-reference with [Breaches](https://www.hackwire.news/category/breaches) and [Malware](https://www.hackwire.news/category/malware)
  • Stay current via the [HackWire homepage](https://www.hackwire.news/)