SURIQ
The wire headline says a CPU attack leaks Linux password hashes. That undersells one half of the story and oversells the other. The new work from MIT is not a single flaw, it is a bug class, and it defeats a design pattern that runs well beyond this one Spectre v2 mitigation. It is also a slow, local read: about five bytes a second, from code that already has to be running on the box. So the group that should act first is narrower than everyone on an Intel or AMD server.
Two researchers at MIT's Computer Science and Artificial Intelligence Laboratory, PhD student Daniël Trujillo and associate professor Mengjia Yan, presented the technique at Black Hat USA and named the class TONTOU, for Time-of-Neutralization to Time-of-Use. The name is the tell. This is the speculative-execution cousin of a TOCTOU file race, where an attacker slips in during the gap between a check and the action it was supposed to protect.
A timing race against the fix, not a new leak
Spectre v2 mitigations work by cleaning the processor's branch predictor so an attacker's earlier, poisoned entries cannot steer sensitive kernel code down a speculative path. The unspoken assumption is that nothing hostile executes between the moment the predictor is sanitized and the moment the kernel relies on it. TONTOU breaks that assumption. An unprivileged program schedules a timer interrupt to fire inside that window and poisons the predictor again once the mitigation has finished, so the protection is undone before the kernel ever leans on it.
According to the researchers, the exploit walks through four stages: neutralize the predictor, redirect execution, poison it again, then let the kernel speculate on the attacker's entries. On an AMD Zen 2 machine running Linux 6.14, they pulled secrets straight out of protected kernel space. The channel is slow, roughly 5.47 bytes each second, and correct about 91.97% of the time. That was still fast enough to recover the /etc/shadow password file on five of ten tries, each success taking around 18 minutes.
Slow is not the same as harmless, but it does shape the threat. This is not a remote exploit and not a one-shot smash. It is a patient side channel that needs a foothold first.
The real precondition is who can run code on the box
Every practitioner question about TONTOU collapses into one: can an untrusted party already execute unprivileged code on this host? If the answer is no, this bug sits far down the queue. If the answer is yes, it moves up.
That framing sorts your fleet fast. Multi-tenant compute, shared CI and build runners, container hosts that schedule other people's workloads, and any box where a low-trust user has a shell are where a slow local read of kernel secrets earns attention. A single-tenant application server where you control every account is a much softer target for this specific technique, because the attacker has to solve the first problem, local execution, before TONTOU is even on the table. The /etc/shadow demo is dramatic, but on most single-purpose servers the harder wall is getting unprivileged code running at all.
This is also why TONTOU belongs in the same mental bucket as the steady drip of Linux local-root bugs we keep writing up: Bad Epoll, the page-cache privilege bugs, the decade-old Open vSwitch flaw, and container escapes that ignore the boundary. None of them matter if nothing untrusted runs locally. All of them matter the moment something does. The control that reduces your exposure to TONTOU is the same one that reduces your exposure to that whole list.
Intel said no. AMD shipped a fix.
The vendor split is the part defenders can act on today, and it is more useful than the leak-rate number. The researchers demonstrated the full chain against AMD's Safe-RET mitigation and reported that the same primitive should work against Intel's eIBRS defense, though they did not show an end-to-end Intel exploit and said it would need extra conditions. They tested on AMD Zen 2 and believe Zen 1 through Zen 4 are affected; on the Intel side they cited Arrow Lake and Cascade Lake Refresh.
The two vendors landed in opposite places. AMD published bulletin AMD-SB-7061, "Safe RET Interrupt Vulnerability," and AMD engineers committed a Linux kernel patch, ahead of the disclosure, that hardens Safe-RET against exactly this interrupt-injection trick. Intel, per reporting, took the opposite view: no patch, and no mitigation deemed necessary, on the argument that exploitation would depend on further conditions. No CVE has been assigned to either.
| AMD | Intel | |
|---|---|---|
| Mitigation targeted | Safe-RET | eIBRS |
| End-to-end exploit shown | Yes, Zen 2, read /etc/shadow | Not yet; believed possible with extra conditions |
| Generations flagged | Zen 1 through Zen 4 | Arrow Lake, Cascade Lake Refresh |
| Vendor response | Bulletin AMD-SB-7061 plus Linux Safe-RET patch | No mitigation required, no patch |
| Your move | Apply the kernel update carrying the fix | No vendor fix; limit local code and watch for updates |
For a mixed fleet that runs both, this rules out the tidy "patch and done" reflex. AMD hosts have a concrete kernel update to schedule. Intel hosts get no vendor action to wait on, so the compensating control, controlling who can run local code, is the only lever you hold. Treating the two the same, in either direction, wastes effort on one and leaves the other exposed.
Patch state is the control, not a SIEM rule
Be honest about detection. A speculative side channel leaves no clean log signature, no dropped file, no network callback you can alert on. There is no hunt query that catches the interrupt timing itself. Anyone selling you a TONTOU detection rule is selling you comfort.
The defensible controls are the boring ones. Track kernel patch state across the fleet and confirm the Safe-RET fix lands on AMD hosts on your normal maintenance cadence, treating it as a standard update rather than an emergency, given the local precondition. Tighten who can run unprivileged code on sensitive machines, and treat shared-compute and multi-tenant boxes as the higher tier. Monitoring the patch state and the local-execution surface across your servers is exactly the kind of continuous coverage a managed vulnerability detection program is meant to give you, because the thing that closes this hole is knowing which hosts are behind and which ones let untrusted code run.
TONTOU will not be the last attack of its shape. The durable lesson is the pattern in the name: any defense that runs once and then trusts that nothing hostile executes before the protected code is a candidate for the same interrupt-timing trick. Safe-RET was the first to fall in public. It is worth asking which of your other run-once mitigations rest on the same assumption.