CVE-2026-43253

What it actually does

This is a Linux kernel availability flaw in the AMD IOMMU driver. When AMD IOMMU strict mode is enabled with `iommu.strict=1`, the kernel can busy-wait for an IOMMU command completion while holding a spinlock with interrupts disabled. Under heavy I/O, DMA, virtualization, or device-mapping pressure, this can cause prolonged CPU stalls, watchdog soft lockups, degraded scheduling, or a system hang. The issue does not provide code execution, privilege escalation, or data disclosure; the primary impact is denial of service.

Why it matters to the business

Affected Linux systems using AMD IOMMU strict mode may become unstable or unavailable during high I/O or virtualization stress, potentially disrupting hosted workloads, storage, networking, or hypervisor operations. The vulnerability is not listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low EPSS score, so broad opportunistic exploitation is not currently indicated; however, systems running latency-sensitive, high-throughput, or multi-tenant workloads may still face operational risk from crashes or lockups.

How an attack unfolds

An attacker or untrusted workload would need to create conditions that force frequent AMD IOMMU command completions while the system is running with strict IOMMU mode enabled. In practice, this could involve generating sustained device I/O, DMA mapping churn, virtual machine activity, containerized workload pressure, or network/storage traffic that indirectly drives IOMMU activity. The vulnerable kernel path waits for hardware completion while holding a spinlock and disabling interrupts, which can starve other kernel activity long enough for watchdogs to report soft lockups or for the host to become unresponsive. There is no indication of public exploit maturity or known exploitation in the wild, and exploitation is best understood as a reliability-triggering denial-of-service condition rather than a direct remote compromise primitive.

How to fix it

Upgrade to a Linux kernel version that includes the AMD IOMMU fix moving `wait_on_sem()` outside the spinlock in `iommu_completion_wait()`. Use the fixed kernel packages provided by the relevant Linux distribution or kernel vendor, because no specific upstream package versions were provided in the input. Where immediate patching is not possible, reduce exposure by avoiding untrusted high-I/O workloads on affected AMD IOMMU systems, limiting device passthrough or DMA-intensive workloads, monitoring for soft lockups, and evaluating whether strict IOMMU mode is operationally required. Do not disable IOMMU protections or strict mode without a risk assessment, because doing so may reduce DMA isolation and hardening.

How to confirm the fix worked

Confirm the running kernel has been updated to a vendor build containing the AMD IOMMU completion-wait fix. Validate that affected systems no longer run an unfixed kernel by checking the installed and booted kernel version with standard OS package and runtime tools. Review boot parameters for `iommu.strict=1` to understand whether the vulnerable execution path was likely reachable before remediation. After patching, perform controlled high-I/O, VM, storage, networking, or device-passthrough stress testing representative of production workloads and confirm that kernel logs no longer show AMD IOMMU-related watchdog stalls, soft lockups, RCU stalls, or host hangs.

Typical attack path

1. Identify or reach a Linux system running an affected kernel on hardware using the AMD IOMMU driver.
2. Confirm or assume that strict IOMMU mode is enabled, commonly via the `iommu.strict=1` kernel parameter or equivalent strict DMA-remapping behavior.
3. Generate sustained I/O, DMA mapping, virtualization, or device passthrough activity that causes frequent AMD IOMMU command completion waits.
4. Trigger contention in the vulnerable AMD IOMMU completion wait path while interrupts are disabled under a spinlock.
5. Cause CPU stalls, kernel watchdog soft-lockup messages, workload disruption, or a full system hang requiring service restart or host reboot.

How to detect it

To determine whether this condition was already triggered, review kernel and system logs for watchdog lockups, RCU stalls, hung tasks, or AMD IOMMU messages around periods of heavy I/O, virtualization, storage, or network activity. Useful sources include `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, hypervisor management logs, hardware management controller event logs, crash dumps, kdump/vmcore artifacts, and monitoring alerts for host unresponsiveness or unexpected reboots. Correlate events with boot parameters showing `iommu.strict=1`, AMD-Vi initialization, VM start/stop activity, device passthrough operations, storage bursts, or network throughput spikes. There are no known attacker-specific payload strings, files, registry keys, or network signatures for this vulnerability; detection is based on kernel availability artifacts and workload correlation.

• watchdog: BUG: soft lockup
• BUG: soft lockup - CPU
• NMI watchdog: Watchdog detected hard LOCKUP
• rcu: INFO: rcu_sched self-detected stall
• rcu: INFO: rcu_preempt self-detected stall
• INFO: task
• blocked for more than
• AMD-Vi
• amd_iommu
• iommu.strict=1
• iommu/amd
• iommu_completion_wait
• wait_on_sem

What your security team should do

• Inventory Linux systems running on AMD platforms with AMD IOMMU enabled, especially hypervisors, storage nodes, network appliances, and high-throughput workload hosts.
• Prioritize patching systems that use `iommu.strict=1`, device passthrough, virtualization, heavy DMA, or untrusted multi-tenant workloads.
• Track distribution kernel advisories and deploy the first vendor-supported kernel containing the AMD IOMMU fix.
• Because this is not KEV-listed, has no known ransomware use, and has low EPSS, prioritize based on operational criticality and exposure to untrusted workload-driven I/O rather than internet exposure alone.
• Review kernel logs from the pre-patch period for soft lockups, hard lockups, RCU stalls, or AMD-Vi/IOMMU errors that coincide with workload spikes.
• Where patching must be delayed, reduce untrusted high-I/O workload density and increase monitoring for host responsiveness and kernel watchdog events.