TONTOU: Linux Kernel Leak via Timer Interrupt Stealing After Spectre v2 Defense Neutralization

1. Basic Information

• Article Title: New TONTOU CPU attack bypasses Spectre v2 fixes, leaks Linux password hashes
• Publisher: BleepingComputer
• Publication Date: August 6, 2026
• Original Source: BleepingComputer
• Primary Source: USENIX Security 2026 Paper / AMD-SB-7061
• Related Products/Technologies: AMD Zen 2, Intel eIBRS, AMD Safe RET, Linux, Spectre v2, Inception, RSB
• Severity: Medium

2. Executive Summary

An attacker who already runs unprivileged code inserts a timer interrupt into kernel processing. The attacker re-poisons the branch predictor after Spectre v2 defenses neutralize it, but before the kernel actually uses the branch. This attack speculatively leaks kernel memory.

3. Attack Flow

AMD Zen 2 Demonstration Chain

1. The attacker runs arbitrary unprivileged native code on the target Linux system.
2. A victim branch in the kernel neutralizes the predictor and RSB through mitigation.
3. The attacker triggers a timer interrupt at the targeted moment, redirecting the kernel to the handler.
4. The attacker poisons the microarchitectural predictor state during the handler path.
5. Execution returns to the original kernel process, and the neutralized victim branch uses the poisoned state.
6. The attacker measures cache side effects of speculative execution to recover kernel data.
7. The attacker combines this with the Inception technique to search for and extract data from /etc/shadow.

Intel Chain

This attack is applicable to eIBRS in theory. However, researchers noted that the Intel chain requires extra software conditions and is more complex than the AMD demonstration.

4. Attacker Position and Execution Location

• Not a standalone remote attack. The attacker must already execute unprivileged native code within the target host, container, or VM.
• The leak target is kernel memory. The attacker observes this through timing and cache measurements in their own process.
• The interrupt, handler, and victim branch share microarchitectural state on the same CPU core.

5. Visibility for Victims and Administrators

The attack does not cause normal authentication failures or file read events. The attacker process may show heavy timing measurements, timer settings, CPU affinity, and a high repetition rate. The research implementation is slow and noisy, making it difficult to detect with standard EDR tools alone.

6. Success and Failure Conditions

Success Conditions

• Unprivileged native code is already running on the target.
• A vulnerable CPU, OS, and mitigation combination is present.
• Victim branches, interrupt timing, and poison gadgets are stable.
• Long-duration repeated measurements are allowed.

Failure Conditions

• Vendor microcode or kernel mitigations are applied.
• Untrusted native code is isolated from the host.
• Multi-tenant workloads are separated, and least privilege is applied.
• High-resolution timer and performance counter restrictions make implementation unstable (effectiveness depends on the environment).

7. What Happens Upon Success

Data in the kernel address space leaks without normal access control checks. Research showed 5.47 bytes/s with 91.97% accuracy on AMD Zen 2 / Linux, extracting data equivalent to /etc/shadow in 5 attempts out of 10, with an average time of 18 minutes.

8. Observable Logs

• Email: None.
• Proxy/SWG/DNS: Only if the attacker downloads initial payloads or sends results. The exploit itself does not require a network.
• Endpoint/EDR: Untrusted native binaries, CPU affinity, timer/interrupt-intensive activity, long CPU usage, and subsequent password cracking without directly opening credential files.
• Identity/IdP: Subsequent successful logins and password cracking using leaked hashes.
• SaaS/Cloud: Tenant boundary signals on shared hosts, CI runners, containers, or VM platforms.
• Network: Subsequent use of credentials, and egress of hashes or extracted data.

9. Attack Success Determination

• Contact Only: CPU/OS fingerprinting and gadget discovery.
• User Action: None required, but prior code execution is necessary.
• Initial Execution: Execution of timer, poison, and timing loops.
• Malware Success: Reproducible kernel byte leaks.
• Data Theft: Recovery and external storage of secrets or hashes.
• Subsequent Compromise Confirmation: Logins using cracked credentials, privilege escalation, and lateral movement.

10. Investigation Playbook

• Trigger: Research PoCs or tools, abnormal timer/timing workloads on shared hosts, or abnormal credential usage.
• Initial Check: Identify CPU model, microcode, kernel, mitigation status, and the origin of untrusted code.
• Endpoints: Preserve binaries, process affinity, performance and timer usage, CPU time, and core scheduling.
• Authentication/Cloud: If hash leaks are suspected, rotate local and service credentials and check for subsequent logins.
• Subsequent Actions: Investigate cracking tools, dump files, egress, and privilege escalation.
• Containment: Isolate processes or hosts, apply vendor mitigations, move workloads, and rotate credentials.
• Determination Levels: Exposed / PoC Present / Timing Activity / Byte Leak / Secret Recovered / Credential Used

11. Defense and Detection Ideas

• Single Event: Known PoC hashes, untrusted process manipulation of performance counters, timers, or affinity, and abnormally long CPU usage.
• Time-Series Correlation: Native payload $\rightarrow$ CPU fingerprint $\rightarrow$ timer/interrupt loop $\rightarrow$ cache measurement $\rightarrow$ cracking/login.
• Hunting: High-CPU, low-I/O processes repeating actions on shared Linux hosts, core pinning, performance counters, and subsequent password attempts.
• Log Gaps: Interrupt and performance events, microcode, mitigation status, container host processes, and cache timing.
• Priority Actions: Vendor updates, isolation of untrusted code, re-evaluation of multi-tenant environments, credential rotation procedures, and avoiding reliance solely on EDR.

12. Facts / Inference / Hypothesis

Facts

• TONTOU exploits the time window after neutralization and before branch use.
• It can bypass the design assumptions of AMD Safe RET and Intel eIBRS.
• Demonstrations on AMD Zen 2 and Linux showed kernel memory leaks and searches for /etc/shadow.
• Prior unprivileged code execution is required.

Inference

• Shared CI environments, hosting platforms, research compute clusters, and container hosts carry higher risk than single-tenant endpoints.
• Even without direct read logs for /etc/shadow, subsequent credential anomalies may serve as the first visible signal.

Hypothesis

• More stable gadgets and timer controls could improve leak speed and success rates.
• Combining eBPF, performance counters, and interrupt telemetry may help distinguish research implementations from normal behavior.

13. MITRE ATT&CK Mapping

• High Confidence: T1003 OS Credential Dumping (recovering password hashes from kernel leaks).
• Medium Confidence: T1068 Exploitation for Privilege Escalation, T1082 System Information Discovery, T1041 Exfiltration Over C2 Channel (during subsequent data transfer).
• ATT&CK does not represent microarchitectural side channels in detail, so mapping confidence is limited.

14. Unknowns and Further Investigation

• Affected CPU generations and microcode/kernel matrices.
• Additional software conditions required for Intel.
• Completeness and performance impact of vendor mitigations.
• Public PoCs, active exploitation, and cloud provider responses.
• Scope of exploitation across container and VM boundaries.

15. Impact on SOCs and General Enterprises

Shared Linux environments, CI runners, hosting platforms, HPC clusters, and R&D infrastructure carry higher priority than general user endpoints. SOCs cannot easily detect this using IOCs alone. Security teams must collaboratively manage platform inventories, OS versions, CPU microcode, kernel states, and untrusted code execution boundaries with platform and OS teams.

16. Summary by Target Audience

• For SOCs: Correlate PoC/process behavior with subsequent credential usage. Do not rely on the absence of direct file read events as proof of safety.
• For Administrators: Apply vendor updates, isolate workloads, inventory CPUs and kernels, and re-evaluate risks on shared hosts.
• For Users: This attack does not trigger directly through normal operations. Do not execute unapproved binaries or unknown compute workloads.