New TONTOU CPU Attack Bypasses Spectre v2 Mitigations, Leaks Linux Password Hashes

Two research results now show Spectre v2 mitigations failing on current hardware, and they fail for different reasons. MIT CSAIL's TONTOU attack, time-of-neutralization-to-time-of-use, lets an unprivileged process inject timer interrupts that re-poison branch predictor state in the window after the kernel neutralizes it with eIBRS on Intel or Safe RET on AMD and before the CPU uses it. On a fully mitigated AMD Zen 2 host the exploit read arbitrary kernel memory, including /etc/shadow, at 5.47 bytes per second with 91.97 percent accuracy, locating the shadow file in five of ten runs at roughly 18 minutes each. VUSec's Branch Target Reuse (BTR) attacks the same predictor from the other side: stale BTB entries survive code replacement, so recycled JIT memory yields a speculative execute-after-free primitive, and their end-to-end exploit against Linux's classic BPF JIT recovered a root password hash from the su process on modern Intel systems with mitigations enabled. AMD has published an advisory tying the interrupt-injection issue to Linux's Safe RET implementation; Intel systems are affected too, with added complexity.

Both results break the same assumption: every Spectre v2 defense deployed since the 2018 disclosures assumes that predictor state, once neutralized, stays neutralized until used. TONTOU breaks the staying part, BTR breaks the once part, so the mitigation model is structurally incomplete rather than merely mis-tuned, and no amount of re-tuning eIBRS or Safe RET closes it on its own. The practical meaning for a victim is that any unprivileged foothold on a patched host becomes a slow but dependable kernel-memory read, and 5.47 bytes per second is fast enough to exfiltrate fixed high-value secrets like root password hashes within minutes. That collapses the tenant boundary on multi-tenant hosts, CI runners, and shared build fleets where sandbox isolation is the actual product. The story carries no CVE id, no KEV listing, and a modest score, but it reopens a bug class the industry had budgeted as closed, which is exactly the kind of item that ages badly if skipped.

Concrete posture work starts with inventory: identify hosts whose Spectre v2 stance rests on eIBRS or Safe RET, since those are the two mechanisms under attack. Apply the guidance in AMD's advisory and take the Safe RET kernel updates as distributions ship them, plus Intel microcode follow-ups when they land. Treat the untrusted-code boundary as the control point: restrict unprivileged timer-injection primitives where the platform permits it, and on hosts running untrusted JIT workloads consider disabling the kernel BPF JIT until vendor fixes arrive. For hunting, look for unprivileged processes installing unusual numbers of seccomp-filter programs, the footprint the BTR exploit builds against the cBPF JIT, and for long-lived processes showing sustained timing activity consistent with an 18-minute, 5.47-bytes-per-second leak loop on otherwise quiet hosts.

Two developments would move this assessment. A CVE id on AMD's advisory, or a matching Intel one, would convert this from research into patch-tracking work with a concrete remediation target. And either proof of concept appearing as public weaponized tooling, rather than a lab demo measured in bytes per second, would shift exploitation status from theoretical to observed.