<?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://cve.radiocsirt.org</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>Sat, 03 Oct 2026 23:40:16 +0000</lastBuildDate>
    <item>
      <title>bdu:2022-00335</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2022-00335</link>
      <description>bdu:2022-00335</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2022-00335</guid>
    </item>
    <item>
      <title>certfr-2021-avi-453 — De multiples vulnérabilités ont été découvertes dans Xen. Elles
permettent à un attaquant de provoquer un déni de servi…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2021-avi-453</link>
      <description>certfr-2021-avi-453</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2021-avi-453</guid>
    </item>
    <item>
      <title>EUVD-2026-26068</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-26068</link>
      <description>EUVD-2026-26068</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-26068</guid>
    </item>
    <item>
      <title>fkie_cve-2021-28692</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2021-28692</link>
      <description>&lt;p&gt;inappropriate x86 IOMMU timeout detection / handling IOMMUs process commands issued to them in parallel with the operation of the CPU(s) issuing such commands. In the current implementation in Xen, asynchronous notification of the completion of such commands is not used. Instead, the issuing CPU spin-waits for the completion of the most recently issued command(s). Some of these waiting loops try to apply a timeout to fail overly-slow commands. The course of action upon a perceived timeout actually being detected is inappropriate: - on Intel hardware guests which did not originally cause the timeout may be marked as crashed, - on AMD hardware higher layer callers would not be notified of the issue, making them continue as if the IOMMU operation succeeded.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;inappropriate x86 IOMMU timeout detection / handling IOMMUs process commands issued to them in parallel with the operation of the CPU(s) issuing such commands. In the current implementation in Xen, asynchronous notification of the completion of such commands is not used. Instead, the issuing CPU spin-waits for the completion of the most recently issued command(s). Some of these waiting loops try to apply a timeout to fail overly-slow commands. The course of action upon a perceived timeout actually being detected is inappropriate: - on Intel hardware guests which did not originally cause the timeout may be marked as crashed, - on AMD hardware higher layer callers would not be notified of the issue, making them continue as if the IOMMU operation succeeded.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2021-28692</guid>
    </item>
    <item>
      <title>GHSA-23j5-p74r-rvqm</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-23j5-p74r-rvqm</link>
      <description>&lt;p&gt;inappropriate x86 IOMMU timeout detection / handling IOMMUs process commands issued to them in parallel with the operation of the CPU(s) issuing such commands. In the current implementation in Xen, asynchronous notification of the completion of such commands is not used. Instead, the issuing CPU spin-waits for the completion of the most recently issued command(s). Some of these waiting loops try to apply a timeout to fail overly-slow commands. The course of action upon a perceived timeout actually being detected is inappropriate: - on Intel hardware guests which did not originally cause the timeout may be marked as crashed, - on AMD hardware higher layer callers would not be notified of the issue, making them continue as if the IOMMU operation succeeded.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;inappropriate x86 IOMMU timeout detection / handling IOMMUs process commands issued to them in parallel with the operation of the CPU(s) issuing such commands. In the current implementation in Xen, asynchronous notification of the completion of such commands is not used. Instead, the issuing CPU spin-waits for the completion of the most recently issued command(s). Some of these waiting loops try to apply a timeout to fail overly-slow commands. The course of action upon a perceived timeout actually being detected is inappropriate: - on Intel hardware guests which did not originally cause the timeout may be marked as crashed, - on AMD hardware higher layer callers would not be notified of the issue, making them continue as if the IOMMU operation succeeded.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-23j5-p74r-rvqm</guid>
    </item>
    <item>
      <title>gsd-2021-28692</title>
      <link>https://cve.radiocsirt.org/vuln/gsd-2021-28692</link>
      <description>gsd-2021-28692</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/gsd-2021-28692</guid>
    </item>
    <item>
      <title>openSUSE-SU-2021:1236-1 — Security update for xen</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2021:1236-1</link>
      <description>&lt;p&gt;Security update for xen&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Security update for xen&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/opensuse-su-2021:1236-1</guid>
    </item>
    <item>
      <title>SUSE-SU-2021:14848-1 — Security update for xen</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2021:14848-1</link>
      <description>&lt;p&gt;Security update for xen&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Security update for xen&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/suse-su-2021:14848-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2021-28692</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2021-28692</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: xen, Ubuntu:18.04:LTS: xen, Ubuntu:20.04:LTS: xen, Ubuntu:22.04:LTS: xen, Ubuntu:24.04:LTS: xen, Ubuntu:25.10: xen, Ubuntu:26.04:LTS: xen&lt;/p&gt;
&lt;p&gt;inappropriate x86 IOMMU timeout detection / handling IOMMUs process commands issued to them in parallel with the operation of the CPU(s) issuing such commands. In the current implementation in Xen, asynchronous notification of the completion of such commands is not used. Instead, the issuing CPU spin-waits for the completion of the most recently issued command(s). Some of these waiting loops try to apply a timeout to fail overly-slow commands. The course of action upon a perceived timeout actually being detected is inappropriate: - on Intel hardware guests which did not originally cause the timeout may be marked as crashed, - on AMD hardware higher layer callers would not be notified of the issue, making them continue as if the IOMMU operation succeeded.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: xen, Ubuntu:18.04:LTS: xen, Ubuntu:20.04:LTS: xen, Ubuntu:22.04:LTS: xen, Ubuntu:24.04:LTS: xen, Ubuntu:25.10: xen, Ubuntu:26.04:LTS: xen&lt;/p&gt;
&lt;p&gt;inappropriate x86 IOMMU timeout detection / handling IOMMUs process commands issued to them in parallel with the operation of the CPU(s) issuing such commands. In the current implementation in Xen, asynchronous notification of the completion of such commands is not used. Instead, the issuing CPU spin-waits for the completion of the most recently issued command(s). Some of these waiting loops try to apply a timeout to fail overly-slow commands. The course of action upon a perceived timeout actually being detected is inappropriate: - on Intel hardware guests which did not originally cause the timeout may be marked as crashed, - on AMD hardware higher layer callers would not be notified of the issue, making them continue as if the IOMMU operation succeeded.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2021-28692</guid>
    </item>
  </channel>
</rss>
