<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Tue, 29 Sep 2026 21:57:28 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-68329 — iommu/amd: Wait for completion instead of returning early in iommu_completion_wait()</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-68329</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;iommu/amd: Wait for completion instead of returning early in iommu_completion_wait()&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;iommu_completion_wait() read need_sync locklessly and returned early
when it was false. This breaks the &amp;#34;block until all previously queued
commands have completed&amp;#34; contract in a multi-CPU scenario:&lt;/p&gt;
&lt;p&gt;CPU2: queue inv-B                  =&amp;gt; need_sync = true
  CPU1: queue CWAIT(N); need_sync = false; then wait_on_sem(N)
  CPU2: read need_sync == false      =&amp;gt; return 0 (no wait!)&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;Fix it without losing the optimization of avoiding redundant CWAIT
commands: take iommu-&amp;gt;lock before testing need_sync, and when it is
false do not return early but wait for the last allocated…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;iommu/amd: Wait for completion instead of returning early in iommu_completion_wait()&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;iommu_completion_wait() read need_sync locklessly and returned early
when it was false. This breaks the &amp;#34;block until all previously queued
commands have completed&amp;#34; contract in a multi-CPU scenario:&lt;/p&gt;
&lt;p&gt;CPU2: queue inv-B                  =&amp;gt; need_sync = true
  CPU1: queue CWAIT(N); need_sync = false; then wait_on_sem(N)
  CPU2: read need_sync == false      =&amp;gt; return 0 (no wait!)&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;Fix it without losing the optimization of avoiding redundant CWAIT
commands: take iommu-&amp;gt;lock before testing need_sync, and when it is
false do not return early but wait for the last allocated…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-68329</guid>
    </item>
  </channel>
</rss>
