Interrupt Injection Bypasses Spectre v2 Defenses on Intel and AMD: Linux Detection, Validation, and Hardening Guide

MIT CSAIL researchers Daniël Trujillo and Mengjia Yan have disclosed INTERRUPT INJECTION, a new transient-execution technique that can bypass Spectre v2 defenses on Intel and AMD CPUs. The core finding is uncomfortable for anyone who assumed the current retpoline/IBRS/IBPB/STIBP stack had closed this class: an unprivileged Linux program can time a hardware interrupt so it lands in the narrow gap after the processor has sanitized branch-predictor state and before the kernel consumes that state, re-poisoning the predictor after the defense has already executed.

The public summary specifically calls out an AMD Zen 2 system running Linux 6.14 with every default Spectre v2 mitigation enabled. No CVE identifier is provided in the source item, and defenders should not invent one. Treat this as an emerging CPU-side-channel research disclosure with clear defensive relevance, especially for multi-tenant compute, CI runners, container hosts, VDI, and any Linux estate where untrusted local code can execute.

Why this matters now

This is not a remote code execution bug and it does not hand an attacker root by itself. The risk is confidentiality failure under a very common 2026 deployment model: mutually distrustful workloads share cores, SMT siblings, and kernel attack surface. A local unprivileged process that can influence interrupt timing may be able to infer kernel data across mitigation boundaries, weaken KASLR, or recover secrets that Spectre v2 controls were expected to protect.

The urgency is highest for:

• Public cloud and private virtualization platforms running customer workloads on shared Intel/AMD hosts.
• Kubernetes, OpenShift, and bare-metal container nodes with untrusted builds, jobs, or sandbox escapes.
• Linux VDI and jump hosts where multiple users execute code on the same machine.
• High-assurance environments that disabled SMT or added strict tenant isolation specifically because of Spectre/Meltdown-class risk.

If your threat model excludes local untrusted execution entirely, prioritize validation over emergency change. If you run multi-tenant Linux, assume this will be operationalized by stronger adversaries and start measuring exposure now.

Technical analysis

Affected platforms: the source names Intel and AMD CPUs broadly and confirms a demonstration on AMD Zen 2 with Linux 6.14 and default Spectre v2 mitigations enabled. Do not read 'Zen 2 confirmed' as 'only Zen 2 affected.' The technique targets a generic race between interrupt delivery and branch-predictor sanitization, so any x86 platform whose Spectre v2 mitigation depends on clearing or isolating predictor state at kernel entry/context-switch boundaries should be treated as potentially exposed until CPU and kernel vendors say otherwise.

Attack chain from a defender perspective:

1. An unprivileged Linux process executes on the target and prepares branch-predictor training from user space.
2. The process arranges or waits for a hardware interrupt to arrive at a precise point in the kernel entry path.
3. The kernel performs its normal Spectre v2 hygiene: branch-predictor sanitization or isolation before relying on predictor state.
4. The interrupt lands in the gap after that sanitization but before protected indirect branches are consumed.
5. Attacker-controlled predictor influence is reintroduced after the defense, allowing speculative mistraining to affect later kernel execution.
6. A cache/timing side channel is used to infer whether protected speculative paths were taken, turning microarchitectural state into leaked information.

Exploitation requirements are non-trivial but realistic for capable attackers: local code execution, precise timing, the ability to steer or survive interrupt delivery, and enough repetition to extract signal through noise. It does not require a malicious driver, root, or a new memory-corruption primitive. That makes the important control boundary 'untrusted code on the host,' not 'remote network reachability.'

Exploitation status: based only on the provided item, this is a named research technique with a demonstrated bypass on at least one AMD Zen 2/Linux 6.14 configuration. There is no CVE in the source, no confirmed CISA KEV listing, and no confirmed in-the-wild campaign in the material provided. Plan as if proof-of-concept code and vendor guidance will evolve quickly; do not claim active exploitation unless your telemetry or a vendor advisory proves it.

Immediate validation commands:

# Kernel, CPU, microcode, and mitigation posture
uname -a
cat /proc/cpuinfo | egrep -m1 'vendor_id|model name|stepping|microcode'
cat /sys/devices/system/cpu/vulnerabilities/spectre_v2
cat /proc/cmdline

# SMT and topology exposure for multi-tenant hosts
cat /sys/devices/system/cpu/smt/active
lscpu | egrep 'Model name|Thread|Core|Socket|NUMA|CPU\(s\)'

# Unprivileged attack-surface settings that commonly amplify side-channel work
sysctl kernel.perf_event_paranoid
sysctl kernel.unprivileged_bpf_disabled
sysctl user.max_user_namespaces

# Firmware and package currency
dmesg | grep -i microcode | head -20
rpm -qa | egrep 'microcode|linux-firmware|kernel' 2>/dev/null || dpkg -l | egrep 'microcode|linux-firmware|linux-image'

Interpretation: a line such as 'Mitigation: Retpolines' or 'IBRS/IBPB/STIBP enabled' is not proof of safety against this race. It proves the legacy controls are on. The open question is whether your kernel and microcode close the interrupt-window gap described by MIT CSAIL.

Detection and response

Direct detection of predictor poisoning is not realistic from user-space telemetry. Hunt for the precursor behaviors an unprivileged researcher or implant would need: high-resolution timing loops, CPU pinning/isolation, perf/MSR access, scheduler manipulation, and suspicious changes to side-channel-relevant sysctls. Keep these as hunting analytics, not brittle blocking controls.

---
title: Linux Unprivileged Timing And CPU Isolation Tooling
description: Hunts for unprivileged use of scheduler, CPU-affinity, or timing tools consistent with transient-execution side-channel preparation such as Interrupt Injection research.
references:
  - https://thehackernews.com/2026/08/new-interrupt-injection-attack-can.html
author: Security Arsenal
date: 2026/08/15
status: experimental
tags:
  - attack.discovery
  - attack.t1059
logsource:
  category: process_creation
  product: linux
detection:
  selection_img:
    Image|endswith:
      - '/chrt'
      - '/taskset'
      - '/perf'
      - '/rdmsr'
      - '/wrmsr'
      - '/turbostat'
  selection_cli:
    CommandLine|contains:
      - 'isolcpus'
      - 'nohz_full'
      - 'rcu_nocbs'
      - 'perf_event_paranoid'
      - '/dev/cpu/'
      - 'rdtsc'
      - 'sched_setaffinity'
  condition: selection_img or selection_cli
falsepositives:
  - Performance engineers, kernel developers, benchmark jobs, and low-latency trading or HPC workloads
level: low
---
title: Linux Side-Channel Surface Modified Via Sysctl Or Debug Paths
description: Detects changes or reads of side-channel-relevant kernel controls and CPU vulnerability state that may precede or follow local transient-execution testing.
references:
  - https://thehackernews.com/2026/08/new-interrupt-injection-attack-can.html
author: Security Arsenal
date: 2026/08/15
status: experimental
tags:
  - attack.defense_evasion
  - attack.discovery
logsource:
  category: process_creation
  product: linux
detection:
  selection:
    CommandLine|contains:
      - '/sys/devices/system/cpu/vulnerabilities/spectre_v2'
      - 'kernel.perf_event_paranoid'
      - 'kernel.unprivileged_bpf_disabled'
      - 'mitigations='
      - 'spectre_v2'
      - 'nosmt'
falsepositives:
  - Hardening scripts, compliance scanners, configuration management, and incident response triage
level: medium

// Hunt Linux endpoint telemetry for local side-channel preparation and mitigation inspection
let terms = dynamic(['chrt','taskset','perf','rdmsr','wrmsr','turbostat','isolcpus','nohz_full','rcu_nocbs','perf_event_paranoid','spectre_v2','mitigations=','nosmt','/dev/cpu/']);
union isfuzzy=true
(DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where ProcessCommandLine has_any (terms) or FileName in~ ('chrt','taskset','perf','rdmsr','wrmsr','turbostat')
| project TimeGenerated, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessAccountName),
(Syslog
| where TimeGenerated > ago(7d)
| where SyslogMessage has_any (terms)
| project TimeGenerated, HostName, ProcessName, SyslogMessage, SeverityLevel),
(CommonSecurityLog
| where TimeGenerated > ago(7d)
| where Message has_any (terms)
| project TimeGenerated, DeviceHostName, DeviceProcessName, Message, SourceUserName)
| order by TimeGenerated desc

-- Hunt for local processes consistent with transient-execution side-channel setup
SELECT Pid,
       Name,
       CommandLine,
       Exe,
       Username,
       CreateTime
FROM pslist()
WHERE CommandLine =~ '(chrt|taskset|perf|rdmsr|wrmsr|turbostat|isolcpus|nohz_full|rcu_nocbs|perf_event_paranoid|spectre_v2|mitigations=|nosmt|/dev/cpu/)'
   OR Exe =~ '/(chrt|taskset|perf|rdmsr|wrmsr|turbostat)$'

Response actions when these analytics fire: capture the full command lineage, parent process, container ID or cgroup, user namespace, SSH/session source, CPU affinity, and whether the workload was expected benchmarking. Preserve /proc/cmdline, vulnerability sysfs output, loaded kernel modules, eBPF/perf state, and package versions before reboot. If the process is untrusted and multi-tenant isolation is in scope, migrate neighbors off the host or cordon the node while you validate.

Hardening and remediation script

There is no universal patch named in the provided source, so do not fabricate a fixed version. The safe operational move is to verify posture, reduce untrusted local attack surface, and be ready to apply kernel/microcode updates the moment Intel, AMD, kernel.org, or your distribution publishes Interrupt Injection-specific guidance.

#!/usr/bin/env bash
# Collect-only by default. Set HARDEN=1 to apply conservative sysctl reductions for untrusted local code.
set -u
out=/var/log/interrupt-injection-triage-$(date +%Y%m%d%H%M%S).log
{
  echo '== identity =='
  uname -a
  egrep -m1 'vendor_id|model name|stepping|microcode' /proc/cpuinfo
  echo '== spectre v2 posture =='
  cat /sys/devices/system/cpu/vulnerabilities/spectre_v2 2>/dev/null
  cat /proc/cmdline
  echo '== topology and SMT =='
  cat /sys/devices/system/cpu/smt/active 2>/dev/null
  lscpu | egrep 'CPU\(s\)|Thread|Core|Socket|NUMA|Model name'
  echo '== side-channel-relevant sysctls =='
  sysctl kernel.perf_event_paranoid kernel.unprivileged_bpf_disabled user.max_user_namespaces 2>/dev/null
  echo '== microcode evidence =='
  dmesg | grep -i microcode | head -50
} | tee "$out"

if [ "${HARDEN:-0}" = 1 ]; then
  cat >/etc/sysctl.d/99-sidechannel-reduce.conf <<'EOF'
kernel.perf_event_paranoid = 3
kernel.unprivileged_bpf_disabled = 1
EOF
  sysctl --system
  echo 'HARDEN=1 applied perf/BPF reductions. Reboot still required for kernel/microcode and cmdline changes.' | tee -a "$out"
else
  echo 'Collect-only complete. Review vendor advisories before changing mitigations=, nosmt, or kernel cmdline at scale.' | tee -a "$out"
fi

Prioritized remediation:

• Track vendor channels daily until patched guidance exists: Intel security advisories, AMD security bulletins, kernel.org stable releases, and your distribution security tracker. Use the source disclosure as the initial reference: https://thehackernews.com/2026/08/new-interrupt-injection-attack-can.html
• Do not disable existing Spectre v2 mitigations because they were bypassed in one race. Layered controls still raise cost and may reduce variants.
• For multi-tenant hosts, enforce strong tenant separation: dedicated nodes for hostile workloads, no co-residency of sensitive and untrusted jobs, vCPU pinning away from SMT siblings where supported, and evaluate nosmt only after workload-capacity testing.
• Restrict unprivileged perf and eBPF where business impact allows: kernel.perf_event_paranoid=3, kernel.unprivileged_bpf_disabled=1, controlled sudo for perf, and policy gates for low-latency tuning tools such as chrt and taskset on shared nodes.
• Patch through normal emergency change once kernel/microcode updates land. Validate in a canary pool that measures compile, JVM, database, and HPC performance before broad rollout.
• Re-run your Spectre-class threat model. If past compensating controls assumed IBPB/retpoline boundaries were absolute, document this gap and update isolation requirements.

Bottom line: Interrupt Injection is a reminder that Spectre v2 defenses are procedural races, not permanent walls. You cannot log the branch predictor directly, so defend the conditions: who can run code, which cores they share, what timing/perf surfaces they can touch, and how fast you can move kernels and microcode when vendor mitigations arrive.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub