CVE-2026-68329: Patch AMD Linux IOMMU Use-After-Free Race

The newly published NVD record, sourced from kernel.org, identifies the defect in

and lists fixed upstream or stable-kernel versions: Linux 6.6.148, 6.12.101, 6.18.42, 7.1.6, and 7.2-rc5. NVD has not assigned CVSS v3 or v4 metrics as of August 11, and neither the NVD entry nor the kernel record identifies a proof-of-concept, exploit campaign, or distribution package release.

The security consequence is more serious than the bland “wait for completion” patch title suggests. The vulnerable code can allow page-table memory to be freed while an AMD IOMMU still holds and may use stale translations for DMA. That creates the conditions for a kernel memory use-after-free—not a direct remote compromise by itself, but a failure in a subsystem relied upon to control which physical memory PCIe devices may access.

The race is in what need_sync claims to mean​

The AMD IOMMU driver queues commands such as translation-cache invalidations into a hardware command buffer. Software must sometimes wait until those commands finish before reclaiming memory or changing mappings. AMD’s IOMMU specification describes the

command as the mechanism that serializes software with command processing: it completes only after older commands have executed.

Linux uses a per-IOMMU

flag as an optimization. Queuing work that requires synchronization sets the flag. Queuing a completion-wait command clears it, on the theory that subsequent callers need not enqueue another redundant hardware wait command.

The flaw was treating a cleared flag as proof that no wait was needed at all.

As the kernel.org CVE description explains, one CPU can enqueue an invalidation, while a second CPU queues a completion-wait command and clears

before the hardware has completed that command. A third action on the first CPU can then observe

as false and return immediately—without waiting for the completion sequence number already assigned by the other CPU.

In other words, the old code confused a wait command has been placed in the queue with the work covered by that wait command is finished. Those are fundamentally different states in a hardware FIFO.

That distinction becomes security-relevant when the caller is about to destroy the page tables associated with an invalidated mapping. If the IOMMU is still walking an older translation when Linux frees the relevant page-table pages, the device-side translation engine can access freed kernel memory. Kernel developers characterize the resulting window as a possible use-after-free.

The patch preserves the hardware optimization​

The fix does not turn every synchronization into a new IOMMU command. Instead, it changes the locking and waiting rules around the existing command sequence.

now takes the IOMMU lock before inspecting

. When the flag is true, Linux takes the established path: it allocates a new command-semaphore sequence value, queues a

, releases the lock, and waits for the hardware to signal that sequence.

When

is false, the revised code no longer returns success immediately. It reads the most recently allocated command-semaphore value while holding the lock, releases the lock, and waits for that value instead.

That is a narrowly targeted correction. The false flag still suppresses an unnecessary new

command, but it no longer suppresses the software-side wait for the existing covering command. Because the AMD IOMMU command queue is FIFO-ordered, waiting for that command’s completion guarantees that prior invalidations have finished.

The upstream diff makes another point that administrators should notice: the developers explicitly rejected a memory-barrier-only solution. This was not merely a stale cache visibility problem where stronger ordering primitives would solve it. The flag had been given the wrong semantic meaning in concurrent operation, so the synchronization contract itself had to change.

This is an old code path with a new security label​

The NVD metadata makes CVE-2026-68329 look unusually broad at first glance. It marks Linux as affected beginning with version 3.0, while also listing five current fixed kernel lines. The kernel’s Git range data starts at commit

, a May 2011 AMD-IOMMU completion-wait cleanup by Jörg Rödel.

That historical starting point is important: this is not presented as a flaw introduced by a single 2026 kernel release. The bug sits in the long-lived synchronization design around AMD IOMMU completion waits. The recent CVE publication does not mean every Linux release since 2011 is equally exposed in a practical deployment sense—kernel architectures, caller paths, and vendor backports vary—but it does mean version-number shortcuts are unsafe.

There is also a recent maintenance history behind this area of the driver. In January, AMD engineer Ankit Soni posted and upstreamed a separate fix for concurrent TLB invalidations. That patch moved command-sequence allocation under the IOMMU lock after developers found that allocation outside the lock could queue completion waits out of sequence and cause timeouts. The current issue addresses a different remaining gap: the early return based on an unlocked

check.

Together, the two fixes show why this should be treated as a concurrency correctness issue rather than a single malformed-command bug. One correction made sequence numbering line up with command ordering. CVE-2026-68329 ensures callers actually wait for the already ordered sequence when another CPU has queued the completion command.

Who should patch first​

This is primarily an AMD Linux host issue. A machine must be using the AMD IOMMU driver for the affected code path to matter; an Intel VT-d host uses a different IOMMU driver, and a Windows-only system is outside the scope of this Linux-kernel CVE.

The highest-priority systems are AMD-based hosts where IOMMU translation is an active operational dependency:

• Linux virtualization hosts assigning GPUs, NICs, NVMe controllers, or other PCIe devices to guests through VFIO.
• KVM, QEMU, libvirt, Proxmox, and similar deployments that create and tear down DMA mappings under load.
• Systems using strict IOMMU invalidation behavior, DMA remapping, device isolation, or interrupt remapping.
• Workstations testing GPU passthrough, SR-IOV, or hardware-assisted nested virtualization.

The CVE should not be overstated as a universal “AMD CPU” flaw. The affected component is the Linux AMD IOMMU driver, not the processor’s general execution engine, Radeon graphics stack, Windows AMD chipset driver, or AMD firmware as such. A Linux desktop with IOMMU disabled is not exercising this driver’s hardware synchronization path in the same way as a passthrough host.

For administrators, the immediate task is to check the distribution kernel package version and changelog, not merely the upstream major.minor family. Enterprise and long-term-support distributions routinely backport kernel security fixes without adopting the upstream version number named by NVD. Conversely, an apparently recent kernel may be missing the correction if it predates the relevant stable update or carries a custom vendor tree.

On systems where the risk profile justifies an immediate response, confirm the running release with

, then inspect the vendor’s kernel advisory or package changelog for CVE-2026-68329 or the AMD-IOMMU completion-wait fix. Rebooting into a patched kernel is required; loading modules or restarting virtual machines will not replace code already running in the kernel.

The missing severity score should not delay maintenance​

NVD’s lack of a CVSS assessment leaves security teams without an official severity bucket, but the record provides enough technical detail to prioritize rationally. It describes a kernel-level use-after-free opportunity arising during concurrent IOMMU invalidation and synchronization, yet it does not establish an external attacker entry point, a reliable privilege-escalation chain, or active exploitation.

That places CVE-2026-68329 below an emergency remote-code-execution event for most fleets, while still making it a prompt patch for AMD Linux systems where DMA isolation is part of the security boundary. A hypervisor host that relies on IOMMU mappings to contain guest-assigned devices should not accept a race that can release page-table memory before the IOMMU has stopped using it.

The practical endpoint is straightforward: move AMD-IOMMU Linux hosts to a vendor kernel containing the fix, and verify the running kernel after reboot. The defect lives precisely in the handoff between “invalidation requested” and “hardware is done”—the point at which a system must be correct before it can safely free memory.