CVE-2026-43220

What it actually does

This is a local Linux kernel race condition in the AMD IOMMU driver. Under concurrent IOMMU TLB invalidation activity, the driver can allocate completion sequence values outside the IOMMU lock, allowing completion-wait commands to be queued out of order. That breaks the ordering assumption used by the completion wait path and can cause command completion waits to time out. The practical impact is a kernel-level availability failure: affected systems using AMD IOMMU functionality may hang, stall device I/O, or require recovery/reboot. The CVSS vector indicates local access with low privileges is required, with no expected confidentiality or integrity impact but high availability impact.

Why it matters to the business

An attacker with local access, or a workload able to trigger the vulnerable IOMMU path, may be able to degrade or disrupt Linux hosts using affected AMD IOMMU functionality. This is most relevant for virtualization, device passthrough, high-I/O, and multi-tenant compute environments where IOMMU activity is common. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has no indicated public exploit maturity, and has a very low and flat EPSS score, so broad internet-scale exploitation is unlikely; however, the operational impact can still be serious where host availability is critical.

How an attack unfolds

Exploitation requires local execution on an affected Linux system. An attacker first obtains the ability to run code or control a workload on the host, then generates concurrent activity that causes repeated AMD IOMMU TLB invalidations, such as through device-mapping, virtualization, or other I/O paths that exercise the AMD IOMMU command queue. Because the vulnerable kernel allocates the completion sequence outside the relevant lock, racing invalidation operations can cause completion-wait commands to be queued in an unexpected order. The kernel then waits on a completion sequence that does not complete as expected, producing timeouts and potentially causing device I/O stalls, host instability, or denial of service. There are no provided indications of active exploitation by named threat actors.

How to fix it

Upgrade to a Linux kernel build that includes the AMD IOMMU fix which serializes completion sequence allocation under the IOMMU lock. Because no exact fixed package versions were provided, use the relevant distribution or vendor security advisory to identify the first fixed kernel package for each supported release line, then reboot into the updated kernel. Prioritize systems using AMD processors with IOMMU enabled, virtualization hosts, systems using VFIO/device passthrough, and high-I/O workloads. If immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads, limiting access to device passthrough interfaces such as VFIO, and monitoring for AMD IOMMU timeout messages. Disabling IOMMU may avoid the vulnerable path in some configurations, but it can materially weaken DMA isolation and virtualization security, so it should be considered only as a temporary, risk-accepted workaround after vendor guidance review.

How to confirm the fix worked

Confirm remediation by verifying the running kernel is the vendor-fixed build, not merely that the package is installed. Check the active kernel with `uname -r`, confirm the booted kernel package version against the distribution advisory, and review package changelogs or source patches for the AMD IOMMU change that moves `cmd_sem_val` allocation under `iommu->lock`. Confirm AMD IOMMU is enabled or in use by reviewing boot logs for AMD-Vi/IOMMU initialization messages. After patching and rebooting, monitor `dmesg`, `journalctl -k`, and system logs during representative virtualization or high-I/O workloads for absence of IOMMU completion-wait timeout messages. For fleets, inventory kernel versions and AMD IOMMU usage, then flag systems running affected kernel builds until they have rebooted into fixed versions.

Typical attack path

1. Gain local code execution or control over a workload on an affected Linux host.
2. Identify that the host is running an affected Linux kernel with AMD IOMMU enabled or in active use.
3. Trigger high concurrency in IOMMU-related paths, commonly associated with device assignment, DMA mapping/unmapping, virtualization, or passthrough workloads.
4. Cause concurrent TLB invalidations that race completion sequence allocation and command queuing.
5. Force completion-wait timeouts in the AMD IOMMU command path.
6. Leverage the resulting kernel/device I/O stall or host instability as a denial-of-service condition.

How to detect it

Look for evidence of attempted or successful denial of service through kernel and system logs rather than network indicators. Primary sources are `dmesg`, `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, hypervisor logs, and monitoring alerts for host stalls, device resets, or I/O hangs. Search for AMD IOMMU, AMD-Vi, completion-wait, command queue, and timeout messages, especially when clustered around local user activity, VM lifecycle operations, device passthrough activity, or high-volume I/O workloads. Correlate kernel timeout events with process accounting, auditd, sudo logs, container runtime logs, libvirt/QEMU logs, and VFIO/device assignment activity to identify the workload or user that was active immediately before the stall. There are no known public threat actor indicators or ransomware-specific indicators for this vulnerability from the provided data.

• Completion-Wait loop timed out
• completion wait timed out
• CMD_COMPL_WAIT
• AMD-Vi: Completion-Wait
• AMD-Vi: Command buffer timeout
• AMD-Vi: IOMMU command timeout
• IOMMU command timeout
• iommu/amd
• cmd_sem_val
• wait_on_sem
• /dev/vfio/vfio
• /dev/vfio/

What your security team should do

• Inventory Linux systems using AMD hardware and identify where AMD IOMMU, VFIO, device passthrough, or virtualization workloads are enabled.
• Prioritize patching virtualization hosts, shared compute hosts, and systems where untrusted local users or workloads can run code.
• Apply the vendor-fixed kernel package and reboot; verify the running kernel, not just the installed package version.
• Restrict local access and device passthrough permissions until patching is complete, especially access to VFIO and other device-assignment interfaces.
• Add monitoring for AMD IOMMU completion-wait or command timeout messages in kernel logs.
• Treat repeated IOMMU timeout events correlated with local workload activity as a possible denial-of-service attempt or reliability incident.
• Because EPSS is very low, KEV is false, and exploit maturity is listed as none, handle this as targeted/local availability risk rather than an internet-facing emergency, unless affected hosts support critical services.