# CVE-2026-68329: iommu/amd: Wait for completion instead of returning early in iommu_completion_wait()

> A race condition in the Linux kernel IOMMU driver allows premature returns, leading to use-after-free and potential privilege escalation.

- **Severity:** High 8.8 (`CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H`)
- **Exploited in the wild:** Not known
- **Login needed:** Any signed-in user
- **Attackable:** Local or same network only
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 10 Aug 2026
- **Updated:** 19 Oct 2026
- **Also known as:** BELL-CVE-2026-68329, DEBIAN-CVE-2026-68329, GHSA-2qhp-87pg-jh75, UBUNTU-CVE-2026-68329

## What is CVE-2026-68329?

CVE-2026-68329 is a high-severity vulnerability in Linux, published on 10 Aug 2026. It can only be exploited from the same machine or local network, with no action from the victim.

### Official description

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.

Weakness: CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization)

## Which versions are affected by CVE-2026-68329?


## How do I fix CVE-2026-68329?

Apply the vendor's patch.

## Is CVE-2026-68329 being exploited?

There is no known exploitation of CVE-2026-68329 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2026-68329 and fix it if it is affected.

What it is: CVE-2026-68329 is a high-severity vulnerability in Linux, published on 10 Aug 2026. It can only be exploited from the same machine or local network, with no action from the victim.
Exploitation: There is no known exploitation of CVE-2026-68329 in the wild and no public exploit code.

Affected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page.

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2026-68329/ (Markdown: https://insights.sbomify.com/CVE-2026-68329/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2026-68329
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-68329
- OSV: https://osv.dev/vulnerability/CVE-2026-68329

---
From sbomify Insights: https://insights.sbomify.com/CVE-2026-68329/
Summaries are generated and may contain mistakes; the official description above is the record.