<?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://db.gcve.eu</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>Wed, 30 Sep 2026 23:01:45 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-53281 — iommu/vt-d: Avoid NULL pointer dereference or refcount corruption</title>
      <link>https://db.gcve.eu/vuln/cve-2026-53281</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux, Red Hat Enterprise Linux 10, Red Hat Enterprise Linux 9, Red Hat Enterprise Linux 6, Red Hat Enterprise Linux 7, Red Hat Enterprise Linux 8&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;iommu/vt-d: Avoid NULL pointer dereference or refcount corruption&lt;/p&gt;
&lt;p&gt;Commit 60f030f7418d (&amp;#34;iommu/vt-d: Avoid use of NULL after WARN_ON_ONCE&amp;#34;)
fixed a NULL pointer dereference in an unlikely situation partly.&lt;/p&gt;
&lt;p&gt;If dev_pasid is not found in the dev_pasids list, it remains NULL.
However, the teardown operations are executed unconditionally, this lead
to a NULL pointer dereference or refcount corruption.&lt;/p&gt;
&lt;p&gt;If the domain was never attached to this IOMMU, info will be NULL, which
would cause an immediate dereference when checking --info-&amp;gt;refcnt.&lt;/p&gt;
&lt;p&gt;Even if info is not NULL, decrementing the refcount without having removed
a valid PASID might unbalance the count. This could lead to premature
dropping of the refcount to 0, potentially causing a use-after-free for the
remaining active devices sharing the domain.&lt;/p&gt;
&lt;p&gt;Fix it by returning early if dev_pasid is NULL, before executing the
teardown operations.&lt;/p&gt;
&lt;p&gt;Issue found by AI review and suggested by Kevin Tian.
https://sashiko.dev/#/patchset/20260421031347.1408890-1-zhenzhong.duan%40intel.com&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux, Red Hat Enterprise Linux 10, Red Hat Enterprise Linux 9, Red Hat Enterprise Linux 6, Red Hat Enterprise Linux 7, Red Hat Enterprise Linux 8&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;iommu/vt-d: Avoid NULL pointer dereference or refcount corruption&lt;/p&gt;
&lt;p&gt;Commit 60f030f7418d (&amp;#34;iommu/vt-d: Avoid use of NULL after WARN_ON_ONCE&amp;#34;)
fixed a NULL pointer dereference in an unlikely situation partly.&lt;/p&gt;
&lt;p&gt;If dev_pasid is not found in the dev_pasids list, it remains NULL.
However, the teardown operations are executed unconditionally, this lead
to a NULL pointer dereference or refcount corruption.&lt;/p&gt;
&lt;p&gt;If the domain was never attached to this IOMMU, info will be NULL, which
would cause an immediate dereference when checking --info-&amp;gt;refcnt.&lt;/p&gt;
&lt;p&gt;Even if info is not NULL, decrementing the refcount without having removed
a valid PASID might unbalance the count. This could lead to premature
dropping of the refcount to 0, potentially causing a use-after-free for the
remaining active devices sharing the domain.&lt;/p&gt;
&lt;p&gt;Fix it by returning early if dev_pasid is NULL, before executing the
teardown operations.&lt;/p&gt;
&lt;p&gt;Issue found by AI review and suggested by Kevin Tian.
https://sashiko.dev/#/patchset/20260421031347.1408890-1-zhenzhong.duan%40intel.com&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/cve-2026-53281</guid>
    </item>
  </channel>
</rss>
