CVE-2026-43253: Linux Kernel AMD IOMMU DoS Vulnerability

CVE-2026-43253 Overview

CVE-2026-43253 is a Linux kernel vulnerability in the AMD Input-Output Memory Management Unit (IOMMU) driver. The flaw resides in the completion wait path used when iommu.strict=1 is set. The function wait_on_sem() busy-waits while holding iommu->lock with interrupts disabled, which can produce soft lockups on stressed systems. The kernel maintainers resolved the issue by moving the completion wait in iommu_completion_wait() outside of the spinlock, since polling the hardware-updated cmd_sem does not require the lock.

Critical Impact

Holding iommu->lock during the busy wait increases lock contention and extends the window with interrupts disabled, leading to soft lockups under load on AMD platforms running with strict IOMMU mode.

Affected Products

• Linux kernel — AMD IOMMU driver (drivers/iommu/amd)
• Systems configured with iommu.strict=1
• AMD-based platforms relying on iommu_completion_wait()

Discovery Timeline

• 2026-05-06 - CVE-2026-43253 published to NVD
• 2026-05-06 - Last updated in NVD database

Technical Details for CVE-2026-43253

Vulnerability Analysis

The AMD IOMMU driver issues a completion wait command to the hardware command buffer and then polls a semaphore (cmd_sem) until the IOMMU signals completion. In the affected code path, iommu_completion_wait() invokes wait_on_sem() while still holding iommu->lock with local interrupts disabled. The wait is a busy poll, so the CPU spins inside the critical section until the hardware updates the semaphore value.

Under strict translation mode (iommu.strict=1), every DMA unmap forces an invalidation and completion wait. High DMA pressure causes many CPUs to contend for iommu->lock while one CPU spins with interrupts off. The combined effect is extended IRQ-off windows that the kernel watchdog reports as soft lockups. The fix relocates the busy wait outside the spinlock, because cmd_sem is updated by hardware and does not depend on driver state guarded by the lock.

Root Cause

The root cause is improper scope of a spinlock-protected region. The driver held iommu->lock for longer than required, covering a hardware poll loop that has no shared software state to protect. This is a locking and concurrency design flaw rather than a memory safety issue.

Attack Vector

The condition is triggered by workloads that generate sustained IOMMU command traffic on AMD hardware running strict mode. A local user or workload that drives heavy DMA mapping and unmapping can amplify lock contention and provoke soft lockups, resulting in degraded availability. Remote exploitation is not described in the upstream commit message.

The vulnerability is a kernel availability issue. The upstream patch refactors iommu_completion_wait() so that wait_on_sem() runs after the spinlock is released. See the upstream fixes in Kernel Git Commit 496269d, Kernel Git Commit 715c263, Kernel Git Commit d2a0cac, Kernel Git Commit e15768e, and Kernel Git Commit f2f65b28.

Detection Methods for CVE-2026-43253

Indicators of Compromise

• Kernel log entries containing soft lockup - CPU#N stuck with stack frames pointing to iommu_completion_wait or wait_on_sem in drivers/iommu/amd.
• RCU stall warnings or watchdog BUG messages on AMD hosts running iommu.strict=1.
• Sudden DMA throughput drops on AMD platforms correlated with kernel watchdog events.

Detection Strategies

• Inspect dmesg and /var/log/messages for soft lockup traces referencing AMD IOMMU symbols.
• Compare running kernel version against the fixed commits listed in the upstream references.
• Audit boot parameters in /proc/cmdline to identify hosts using iommu.strict=1, which are the exposed configurations.

Monitoring Recommendations

• Forward kernel ring buffer events to centralized logging and alert on soft lockup and iommu keyword combinations.
• Track host availability metrics (CPU steal, IRQ-off duration) on AMD servers handling high DMA workloads.
• Maintain a current kernel inventory across the fleet to identify unpatched AMD hosts.

How to Mitigate CVE-2026-43253

Immediate Actions Required

• Apply the upstream Linux kernel patches referenced above or update to a stable kernel release that incorporates them.
• Identify AMD hosts running with iommu.strict=1 and prioritize them for patching.
• Reboot patched systems so the corrected iommu_completion_wait() path is loaded.

Patch Information

The fix moves wait_on_sem() out of the iommu->lock critical section in the AMD IOMMU completion wait path. Distribution-supplied kernels that backport commits 496269d, 715c263, d2a0cac, e15768e, or f2f65b28 resolve the soft lockup behavior. Consult vendor advisories from Red Hat, SUSE, Ubuntu, and Debian for backported package versions.

Workarounds

• Where operationally acceptable, switch from iommu.strict=1 to lazy invalidation (iommu.strict=0) to reduce completion-wait pressure until patched kernels are deployed.
• Reduce DMA-intensive workloads on affected AMD hosts during the patch window.
• Pin sensitive workloads to non-AMD hosts or to already-patched nodes if mixed environments are available.

# Check current IOMMU mode and kernel version on AMD hosts
cat /proc/cmdline | tr ' ' '\n' | grep -i iommu
uname -r

# Temporary mitigation: boot with lazy invalidation instead of strict
# Edit /etc/default/grub and update GRUB_CMDLINE_LINUX, e.g.:
#   GRUB_CMDLINE_LINUX="... iommu.strict=0 ..."
sudo update-grub   # Debian/Ubuntu
# or
sudo grub2-mkconfig -o /boot/grub2/grub.cfg   # RHEL/SUSE