Interrupt Injection Vulnerability: When the CPU's Specter v2 "shield" is punctured for a few seconds

Do you think your system is absolutely safe after activating all Specter v2 defense mechanisms? A recent study from MIT CSAIL may make you think again. By simply inserting a hardware interrupt into a microscopic "gap" lasting a few nanoseconds, unprivileged attackers can completely disable AMD's Safe-RET and Intel's eIBRS protection mechanisms. More worryingly, the data leak speed is fast enough to successfully read the entire /etc/shadow file containing the password hash of the Linux operating system. So how exactly does this mechanism work, and is your system in the crosshairs?

Overview

Specter v2 seemed to be under control, but the recently announced "Interrupt Injection" attack technique (belonging to the TONTOU bug group) has completely broken that belief. Taking advantage of a nanosecond time gap, unprivileged attackers can bypass core shields and silently siphon sensitive data directly from kernel memory. This threat is currently covering Linux systems using AMD Zen processors (from generations 1 to 4) and some Intel chip lines, turning Cloud and Shared Hosting environments into "gold mines" easily exploited by users who share physical CPU resources. To prevent a catastrophic leak, system administrators need to immediately update the Linux kernel containing the "x86/bugs: Make Safe-RET robust against interrupt injection" patch before it's too late.

Technical Background

This new vulnerability is named Interrupt Injection, discovered by two researchers Daniël Trujillo and Mengjia Yan from MIT CSAIL. According to security report AMD-SB-7061 (Safe RET Interrupt Vulnerability), this bug affects a series of AMD processor architectures from Zen 1 to Zen 4.

The notable thing about this technique is that it does not require administrator rights. The attacker only needs to be able to execute local code on the target system. This bug exploits a vulnerability in the Linux kernel's handling of the Safe-RET (on AMD) and BHI/eIBRS (on Intel) defense mechanisms. Currently, this vulnerability has not been assigned an independent CVE code but is being monitored through AMD's security bulletin.

Attack Chain

Before diving into Interrupt Injection, we need to understand how a speculative execution attack (like Specter v2) works. Attackers do not go through the main door to steal data, but they take advantage of the CPU's "intelligence" to trick it into revealing secrets through 6 sophisticated steps:

Running malicious code in user space (User Process): The attacker executes a piece of code they wrote themselves at the lowest level of authority (user space). At this time, the system still evaluates this as a harmless program.
Branch Predictor Training: Modern CPUs always try to "guess" what the next instruction is to run first (increase speed). The attacker continuously performs a repetitive action to "train" the branch predictor to believe that the next instruction will definitely go in a particular direction A.
Infiltrating the privileged zone (Kernel Execution): After the CPU has been "brainwashed", the attacker suddenly calls a system command (system call) to request the CPU to switch to the most privileged mode (Kernel mode), where all the most sensitive data is stored.
Speculative Execution: The CPU is in Kernel mode and encounters a branch instruction. According to trained habits, the CPU "guesses" and runs instructions in direction A "blindly" (speculative execution) before realizing that it has guessed wrong. The commands in direction A are malicious commands installed by the attacker to read confidential data.
Save traces on Cache (CPU Cache Effects): Just blink of an eye, the CPU realizes it guessed wrong! It cancels the result and returns to the correct path. But the fatal mistake is that the sensitive data it accidentally read was accidentally saved in the CPU Cache - a shared memory area.
Secret Data Leakage: The attacker measures cache access time (Cache timing attack). Data in the Cache will be loaded faster than RAM, from which the attacker can infer exactly what the Kernel's sensitive data is.

By automating and repeating these 6 steps thousands of times per second, they can completely "suck" important system files.

Exploitation Mechanism: How Does Interrupt Injection Work?

To combat the above attack chain, CPU manufacturers create shields like Safe-RET. The goal is to "sanitize" the state of the branch predictor before the kernel uses it (blocking in Step 3).

However, Interrupt Injection punctures this shield with a timing vulnerability called TONTOU (Time-of-Neutralization to Time-of-Use). This technique intervenes directly in the transition phase between Step 3 and Step 4:

Race condition: The attacker uses a sibling hyperthread to push defensive commands out of the cache. This slows down the system, lengthening the gap between when the branch predictor is "cleaned" and when it is used. On the Zen 2 architecture, this gap is only 6 bytes wide.
Injecting the Interrupt: The attacker schedules hardware interrupts with nanosecond precision so that the interrupt falls into the above 6-byte gap.
Re-poisoning: An interrupt occurs, causing the execution thread to jump to the interrupt handler function. Attackers use this function as a training tool. Combined with the Inception technique (CVE-2023-20569), they populate the Return Stack Buffer (RSB) with destination addresses under their control.
Bypass completed: When the interrupt ends and returns control to the kernel, the branch predictor has been "infected" again, rendering the Safe-RET mechanism completely useless. Step 4 (Speculative Execution) of the Specter attack chain continues as if no protection was ever present.

Recording Actual Exploitation

Under test conditions, the researchers demonstrated that the exploit worked extremely well on the AMD Zen 2 platform (running Linux 6.14 with full default Specter v2 mitigations).

Leak rate: 5.47 bytes/second.
Accuracy: Up to 91.97%.
Severity: The attacker successfully read the entire /etc/shadow file in 5/10 attempts.

For Intel processors (Arrow Lake, Cascade Lake Refresh), the study noted that a branch prediction error (misprediction) has appeared but has not yet built a complete exploit chain (end-to-end exploit) to leak kernel memory. However, researchers believe that exploiting on Intel is completely feasible if existing disclosure gadgets are combined.

MITRE ATT&CK Mapping

T1059 - Command and Scripting Interpreter (Local code execution)
T1559 - Inter-Process Communication (Hardware execution flow control and interaction)
T1003.008 - OS Credential Dumping: /etc/passwd and /etc/shadow (Password hash leak via memory leak)

Detection & Response

Detection: Detecting Interrupt Injection at the network level (Network/SIEM) is almost impossible because the exploit code runs entirely at the local hardware and memory layer. EDR solutions can monitor for unusual behavior such as an unprivileged process continuously making system calls (like write) combined with spikes in hardware interrupts (interrupt storms) at the microsecond level.

Response: Standard IR response to hardware/kernel failure:

Identify affected CPU systems.
Apply the OS kernel patch.
Review the EDR logs to look for signs of local memory scanning.

Expert opinion

The fact that a hardware error can bypass entire software defense mechanisms (like Safe-RET) shows the fragility of current "workaround" solutions. In reality, this technique is not too much of a threat to the end user's personal computer or laptop due to the requirement for local access and having to run the code directly on the machine.

However, for Cloud service providers, VPS or Enterprise Container environments (Kubernetes), this is an extremely serious risk. An attacker can rent a cheap VPS package, run exploit code and "penetrate" into the kernel memory of the physical server (host), thereby extracting sensitive information of other customers (tenants) located on the same CPU.

On the manufacturers side:

AMD has proactively coordinated with the Linux community to release the patch.
Intel currently believes that this risk is covered by the BHI/IMBTI guidance (INTEL-SA-00598) and has no plans to release additional patches. However, organizations using Intel chips should not be subjective.

Recommended Action

Immediate (Immediate - 0 to 24h):

Inventory Check: Scan the entire server system (especially shared host, cloud, virtualization environments) to identify servers using AMD Zen CPUs (from Zen 1 to Zen 4).
Risk assessment: Prioritize updates for servers that allow external/untrusted users to execute local code (e.g. CI/CD runners, Shared Hosting, Terminal servers).

Short-term (1 to 7 days):

Update Linux Kernel: Immediately apply the latest kernel updates from the operating system vendor (Ubuntu, RHEL, CentOS...). You need to make sure your kernel has been updated with the code titled: x86/bugs: Make Safe-RET robust against interrupt injection. This patch readjusts the register state as if the Safe-RET sequence had completed and avoids executing the RET instruction after the interrupt has finished.

Long-term:

Implement Zero Trust & Isolation architecture: For systems containing hyper-sensitive data, consider using separate physical servers (dedicated hosts) to avoid risks from side-channel/speculative execution attacks from other tenants.