<?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>Thu, 15 Oct 2026 20:30:15 +0000</lastBuildDate>
    <item>
      <title>CVE-2025-39958 — iommu/s390: Make attach succeed when the device was surprise removed</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2025-39958</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/s390: Make attach succeed when the device was surprise removed&lt;/p&gt;
&lt;p&gt;When a PCI device is removed with surprise hotplug, there may still be
attempts to attach the device to the default domain as part of tear down
via (__iommu_release_dma_ownership()), or because the removal happens
during probe (__iommu_probe_device()). In both cases zpci_register_ioat()
fails with a cc value indicating that the device handle is invalid. This
is because the device is no longer part of the instance as far as the
hypervisor is concerned.&lt;/p&gt;
&lt;p&gt;Currently this leads to an error return and s390_iommu_attach_device()
fails. This triggers the WARN_ON() in __iommu_group_set_domain_nofail()
because attaching to the default domain must never fail.&lt;/p&gt;
&lt;p&gt;With the device fenced by the hypervisor no DMAs to or from memory are
possible and the IOMMU translations have no effect. Proceed as if the
registration was successful and let the hotplug event handling clean up
the device.&lt;/p&gt;
&lt;p&gt;This is similar to how devices in the error state are handled since
commit 59bbf596791b (&amp;#34;iommu/s390: Make attach succeed even if the device
is in error state&amp;#34;) except that for removal the domain will not be
registered later. This approach was also previously discussed at the
link.&lt;/p&gt;
&lt;p&gt;Handle both cases, error state and removal, in a helper which checks if
the error needs to be propagated or ignored. Avoid magic number
condition codes by using the pre-existing, but never use…&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/s390: Make attach succeed when the device was surprise removed&lt;/p&gt;
&lt;p&gt;When a PCI device is removed with surprise hotplug, there may still be
attempts to attach the device to the default domain as part of tear down
via (__iommu_release_dma_ownership()), or because the removal happens
during probe (__iommu_probe_device()). In both cases zpci_register_ioat()
fails with a cc value indicating that the device handle is invalid. This
is because the device is no longer part of the instance as far as the
hypervisor is concerned.&lt;/p&gt;
&lt;p&gt;Currently this leads to an error return and s390_iommu_attach_device()
fails. This triggers the WARN_ON() in __iommu_group_set_domain_nofail()
because attaching to the default domain must never fail.&lt;/p&gt;
&lt;p&gt;With the device fenced by the hypervisor no DMAs to or from memory are
possible and the IOMMU translations have no effect. Proceed as if the
registration was successful and let the hotplug event handling clean up
the device.&lt;/p&gt;
&lt;p&gt;This is similar to how devices in the error state are handled since
commit 59bbf596791b (&amp;#34;iommu/s390: Make attach succeed even if the device
is in error state&amp;#34;) except that for removal the domain will not be
registered later. This approach was also previously discussed at the
link.&lt;/p&gt;
&lt;p&gt;Handle both cases, error state and removal, in a helper which checks if
the error needs to be propagated or ignored. Avoid magic number
condition codes by using the pre-existing, but never use…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cve-2025-39958</guid>
    </item>
    <item>
      <title>USN-8781-1 — linux-nvidia-tegra vulnerabilities</title>
      <link>https://cve.radiocsirt.org/vuln/usn-8781-1</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:24.04:LTS: linux-nvidia-tegra&lt;/p&gt;
&lt;p&gt;It was discovered that some Arm processors could complete a broadcast
translation lookaside buffer (TLB) invalidation before memory writes made
through the invalidated translation were globally observed. A local
attacker could possibly use this to write to memory after permission to do
so had been revoked, bypassing memory protections or escalating privileges.
(CVE-2025-10263)&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;
  - User-space API (UAPI);
  - Kernel build system;
  - ARM32 architecture;
  - PowerPC architecture;
  - RISC-V architecture;
  - S390 architecture;
  - User-Mode Linux (UML);
  - x86 architecture;
  - Cryptographic API;
  - Intel NPU Driver;
  - Compute Acceleration Framework;
  - ACPI drivers;
  - Drivers core;
  - DRBD Distributed Replicated Block Device drivers;
  - Rados block device (RBD) driver;
  - Ublk userspace block driver;
  - Compressed RAM block device driver;
  - Bluetooth drivers;
  - Hardware crypto device drivers;
  - CXL (Compute Express Link) drivers;
  - Arm Firmware Framework for ARMv8-A(FFA);
  - EFI core;
  - FPGA Framework;
  - GPU drivers;
  - HID subsystem;
  - Hardware monitoring drivers;
  - I2C subsystem;
  - I3C subsystem;
  - InfiniBand drivers;
  - Input Device core drivers;
  - Input Device (Mouse) drivers;
  - IOMMU subsystem;
  - Multiple devices driver;
  - Media…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:24.04:LTS: linux-nvidia-tegra&lt;/p&gt;
&lt;p&gt;It was discovered that some Arm processors could complete a broadcast
translation lookaside buffer (TLB) invalidation before memory writes made
through the invalidated translation were globally observed. A local
attacker could possibly use this to write to memory after permission to do
so had been revoked, bypassing memory protections or escalating privileges.
(CVE-2025-10263)&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;
  - User-space API (UAPI);
  - Kernel build system;
  - ARM32 architecture;
  - PowerPC architecture;
  - RISC-V architecture;
  - S390 architecture;
  - User-Mode Linux (UML);
  - x86 architecture;
  - Cryptographic API;
  - Intel NPU Driver;
  - Compute Acceleration Framework;
  - ACPI drivers;
  - Drivers core;
  - DRBD Distributed Replicated Block Device drivers;
  - Rados block device (RBD) driver;
  - Ublk userspace block driver;
  - Compressed RAM block device driver;
  - Bluetooth drivers;
  - Hardware crypto device drivers;
  - CXL (Compute Express Link) drivers;
  - Arm Firmware Framework for ARMv8-A(FFA);
  - EFI core;
  - FPGA Framework;
  - GPU drivers;
  - HID subsystem;
  - Hardware monitoring drivers;
  - I2C subsystem;
  - I3C subsystem;
  - InfiniBand drivers;
  - Input Device core drivers;
  - Input Device (Mouse) drivers;
  - IOMMU subsystem;
  - Multiple devices driver;
  - Media…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/usn-8781-1</guid>
    </item>
  </channel>
</rss>
