CVE-2026-68329 in Linux
Summary
by MITRE • 08/10/2026
In the Linux kernel, the following vulnerability has been resolved:
iommu/amd: Wait for completion instead of returning early in iommu_completion_wait()
need_sync is a per-IOMMU flag shared by all domains and devices behind that IOMMU. It is set whenever a command is queued with sync == true and cleared when a completion-wait (CWAIT) command is queued. However, a cleared need_sync only means that a covering CWAIT has been queued, not that all previously queued commands have actually completed in hardware.
iommu_completion_wait() read need_sync locklessly and returned early when it was false. This breaks the "block until all previously queued commands have completed" contract in a multi-CPU scenario:
CPU2: queue inv-B => need_sync = true CPU1: queue CWAIT(N); need_sync = false; then wait_on_sem(N) CPU2: read need_sync == false => return 0 (no wait!)
CPU2 returns without waiting for any sequence number even though its inv-B may not have completed yet (CWAIT(N), queued after inv-B, has not been signaled). CPU2 then proceeds to, for example, free page-table pages while the IOMMU can still walk stale translations, opening a use-after-free window. This is a logical race in the meaning of the flag, not a memory-visibility issue, so barriers alone do not help.
Fix it without losing the optimization of avoiding redundant CWAIT commands: take iommu->lock before testing need_sync, and when it is false do not return early but wait for the last allocated sequence number (cmd_sem_val). Since need_sync == false implies no sync command was queued after the last CWAIT, that CWAIT is FIFO-ordered after every not-yet-completed command, so waiting for its sequence number guarantees all prior commands (possibly queued by another CPU) have completed. The common path with pending work is unchanged and no extra hardware command is issued.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/10/2026
The vulnerability exists within the AMD IOMMU subsystem of the Linux kernel where a race condition in the iommu_completion_wait() function creates a potential use-after-free scenario. This issue stems from improper handling of the need_sync flag which serves as a per-IOMMU indicator for command synchronization status. The flag is set when commands are queued with sync == true and cleared when completion-wait commands are queued, but this clearing mechanism only indicates that a covering CWAIT has been queued rather than confirming actual hardware completion of all previously queued commands.
The fundamental flaw occurs in a multi-CPU environment where the iommu_completion_wait() function performs lockless reads of the need_sync flag and returns prematurely when it detects a false value. This violates the expected contract that the function should block until all previously queued commands have completed. The race condition manifests when CPU2 queues an invalidation command inv-B while CPU1 queues a CWAIT command followed by waiting on a semaphore, causing CPU2 to return without ensuring proper synchronization. This creates a window where CPU2 may proceed to free page table pages while the IOMMU continues walking stale translations, resulting in memory corruption vulnerabilities.
This vulnerability maps directly to CWE-362, which describes a race condition that allows concurrent execution of different code paths, and aligns with ATT&CK technique T1059.008 for privilege escalation through kernel exploitation. The logical race in flag interpretation represents more than just a memory visibility issue, as simple memory barriers cannot resolve the fundamental problem with synchronization semantics. The vulnerability demonstrates improper handling of concurrent command queuing and completion tracking across multiple execution contexts.
The fix implements a proper locking mechanism around the need_sync flag testing while preserving the optimization that prevents redundant CWAIT commands from being issued. By acquiring iommu->lock before testing need_sync, the implementation ensures atomic access to synchronization state information. When need_sync is false, instead of returning early, the function now waits for the last allocated sequence number (cmd_sem_val) which provides the correct guarantee that all prior commands have completed. This approach maintains the performance optimization by avoiding unnecessary hardware commands while ensuring proper synchronization semantics, as the CWAIT command that was just queued will be FIFO-ordered after any previously queued commands, making sequence number waiting sufficient to verify completion of all preceding operations.
The solution resolves the race condition without altering the common code path for pending work and maintains the existing performance characteristics. The fix addresses the synchronization issue by ensuring that when need_sync is false, the function waits for the correct sequence number rather than assuming command completion based on flag state alone. This approach prevents the use-after-free vulnerability while preserving the efficiency optimization of avoiding redundant CWAIT commands, making it a targeted and effective remediation that aligns with both security requirements and performance considerations.