<?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>Wed, 14 Oct 2026 22:02:54 +0000</lastBuildDate>
    <item>
      <title>CVE-2025-38062 — genirq/msi: Store the IOMMU IOVA directly in msi_desc instead of iommu_cookie</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2025-38062</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;genirq/msi: Store the IOMMU IOVA directly in msi_desc instead of iommu_cookie&lt;/p&gt;
&lt;p&gt;The IOMMU translation for MSI message addresses has been a 2-step process,
separated in time:&lt;/p&gt;
&lt;p&gt;1) iommu_dma_prepare_msi(): A cookie pointer containing the IOVA address
    is stored in the MSI descriptor when an MSI interrupt is allocated.&lt;/p&gt;
&lt;p&gt;2) iommu_dma_compose_msi_msg(): this cookie pointer is used to compute a
    translated message address.&lt;/p&gt;
&lt;p&gt;This has an inherent lifetime problem for the pointer stored in the cookie
that must remain valid between the two steps. However, there is no locking
at the irq layer that helps protect the lifetime. Today, this works under
the assumption that the iommu domain is not changed while MSI interrupts
being programmed. This is true for normal DMA API users within the kernel,
as the iommu domain is attached before the driver is probed and cannot be
changed while a driver is attached.&lt;/p&gt;
&lt;p&gt;Classic VFIO type1 also prevented changing the iommu domain while VFIO was
running as it does not support changing the &amp;#34;container&amp;#34; after starting up.&lt;/p&gt;
&lt;p&gt;However, iommufd has improved this so that the iommu domain can be changed
during VFIO operation. This potentially allows userspace to directly race
VFIO_DEVICE_ATTACH_IOMMUFD_PT (which calls iommu_attach_group()) and
VFIO_DEVICE_SET_IRQS (which calls into iommu_dma_compose_msi_msg()).&lt;/p&gt;
&lt;p&gt;This potentially causes both the cookie pointer and the unlocked call to
iommu_g…&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;genirq/msi: Store the IOMMU IOVA directly in msi_desc instead of iommu_cookie&lt;/p&gt;
&lt;p&gt;The IOMMU translation for MSI message addresses has been a 2-step process,
separated in time:&lt;/p&gt;
&lt;p&gt;1) iommu_dma_prepare_msi(): A cookie pointer containing the IOVA address
    is stored in the MSI descriptor when an MSI interrupt is allocated.&lt;/p&gt;
&lt;p&gt;2) iommu_dma_compose_msi_msg(): this cookie pointer is used to compute a
    translated message address.&lt;/p&gt;
&lt;p&gt;This has an inherent lifetime problem for the pointer stored in the cookie
that must remain valid between the two steps. However, there is no locking
at the irq layer that helps protect the lifetime. Today, this works under
the assumption that the iommu domain is not changed while MSI interrupts
being programmed. This is true for normal DMA API users within the kernel,
as the iommu domain is attached before the driver is probed and cannot be
changed while a driver is attached.&lt;/p&gt;
&lt;p&gt;Classic VFIO type1 also prevented changing the iommu domain while VFIO was
running as it does not support changing the &amp;#34;container&amp;#34; after starting up.&lt;/p&gt;
&lt;p&gt;However, iommufd has improved this so that the iommu domain can be changed
during VFIO operation. This potentially allows userspace to directly race
VFIO_DEVICE_ATTACH_IOMMUFD_PT (which calls iommu_attach_group()) and
VFIO_DEVICE_SET_IRQS (which calls into iommu_dma_compose_msi_msg()).&lt;/p&gt;
&lt;p&gt;This potentially causes both the cookie pointer and the unlocked call to
iommu_g…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cve-2025-38062</guid>
    </item>
    <item>
      <title>USN-7769-1 — linux, linux-aws, linux-gcp, linux-gcp-6.14, linux-oracle, linux-realtime vulnerabilities</title>
      <link>https://cve.radiocsirt.org/vuln/usn-7769-1</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:24.04:LTS: linux-gcp-6.14&lt;/p&gt;
&lt;p&gt;Several security issues were discovered in the Linux kernel.
An attacker could possibly use these to compromise the system.
This update corrects flaws in the following subsystems:
  - ARM64 architecture;
  - PowerPC architecture;
  - x86 architecture;
  - Block layer subsystem;
  - Cryptographic API;
  - ACPI drivers;
  - Android drivers;
  - Bluetooth drivers;
  - Bus devices;
  - Clock framework and drivers;
  - CPU frequency scaling framework;
  - Hardware crypto device drivers;
  - DMA engine subsystem;
  - EDAC drivers;
  - Arm Firmware Framework for ARMv8-A(FFA);
  - FPGA Framework;
  - GPIO subsystem;
  - GPU drivers;
  - HID subsystem;
  - Hardware monitoring drivers;
  - HW tracing;
  - InfiniBand drivers;
  - IOMMU subsystem;
  - Multiple devices driver;
  - Media drivers;
  - VMware VMCI Driver;
  - MTD block device drivers;
  - Network drivers;
  - Mellanox network drivers;
  - STMicroelectronics network drivers;
  - NVDIMM (Non-Volatile Memory Device) drivers;
  - NVME drivers;
  - NVMEM (Non Volatile Memory) drivers;
  - PCI subsystem;
  - Amlogic Meson DDR PMU;
  - NI-700 PMU driver;
  - PHY drivers;
  - Pin controllers subsystem;
  - x86 platform drivers;
  - PTP clock framework;
  - SCSI subsystem;
  - ASPEED SoC drivers;
  - SPI subsystem;
  - TCM subsystem;
  - Thunderbolt and USB4 drivers;
  - TTY drivers;
  - UFS subsystem;
  - USB core drivers;
  - USB Gadget drivers;
  - Renesas USBHS Controller drivers;
  - USB Type-C Port Controller Manager driver;…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:24.04:LTS: linux-gcp-6.14&lt;/p&gt;
&lt;p&gt;Several security issues were discovered in the Linux kernel.
An attacker could possibly use these to compromise the system.
This update corrects flaws in the following subsystems:
  - ARM64 architecture;
  - PowerPC architecture;
  - x86 architecture;
  - Block layer subsystem;
  - Cryptographic API;
  - ACPI drivers;
  - Android drivers;
  - Bluetooth drivers;
  - Bus devices;
  - Clock framework and drivers;
  - CPU frequency scaling framework;
  - Hardware crypto device drivers;
  - DMA engine subsystem;
  - EDAC drivers;
  - Arm Firmware Framework for ARMv8-A(FFA);
  - FPGA Framework;
  - GPIO subsystem;
  - GPU drivers;
  - HID subsystem;
  - Hardware monitoring drivers;
  - HW tracing;
  - InfiniBand drivers;
  - IOMMU subsystem;
  - Multiple devices driver;
  - Media drivers;
  - VMware VMCI Driver;
  - MTD block device drivers;
  - Network drivers;
  - Mellanox network drivers;
  - STMicroelectronics network drivers;
  - NVDIMM (Non-Volatile Memory Device) drivers;
  - NVME drivers;
  - NVMEM (Non Volatile Memory) drivers;
  - PCI subsystem;
  - Amlogic Meson DDR PMU;
  - NI-700 PMU driver;
  - PHY drivers;
  - Pin controllers subsystem;
  - x86 platform drivers;
  - PTP clock framework;
  - SCSI subsystem;
  - ASPEED SoC drivers;
  - SPI subsystem;
  - TCM subsystem;
  - Thunderbolt and USB4 drivers;
  - TTY drivers;
  - UFS subsystem;
  - USB core drivers;
  - USB Gadget drivers;
  - Renesas USBHS Controller drivers;
  - USB Type-C Port Controller Manager driver;…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/usn-7769-1</guid>
    </item>
  </channel>
</rss>
