<?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>Tue, 13 Oct 2026 06:30:38 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-72103 — dm: avoid leaking the caller's thread keyring via the table device file</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2026-72103</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;dm: avoid leaking the caller&amp;#39;s thread keyring via the table device file&lt;/p&gt;
&lt;p&gt;The refactoring in commit a28d893eb327 (&amp;#34;md: port block device access to file&amp;#34;)
accidentally causes the caller&amp;#39;s thread keyring to be kept alive long
beyond the caller&amp;#39;s lifetime.&lt;/p&gt;
&lt;p&gt;As a result, &amp;#34;cryptsetup luksSuspend&amp;#34; silently fails to wipe the
LUKS volume key from memory.&lt;/p&gt;
&lt;p&gt;In detail: &amp;#34;cryptsetup luksOpen&amp;#34; uses its supposedly ephemeral thread
keyring to pass the volume key to the kernel. dm-crypt&amp;#39;s
crypt_set_keyring_key() copies the key material into its own
crypt_config structure and then drops its own reference to the key in
the keyring with key_put().&lt;/p&gt;
&lt;p&gt;With this fix, restoring pre-v6.9 behavior, the copy in the thread
keyring is then promptly garbage collected, such that exactly one copy
of the volume key remains. This single copy is correctly wiped from
memory on &amp;#34;cryptsetup luksSuspend&amp;#34;.&lt;/p&gt;
&lt;p&gt;Without this fix, the thread keyring and the volume key in it remains.
This second copy is only freed on &amp;#34;luksClose&amp;#34;. &amp;#34;luksSuspend&amp;#34; neither
knows about this copy nor has any way to remove it, so the key remains
recoverable from RAM after a suspend that is documented to have wiped it.&lt;/p&gt;
&lt;p&gt;This fix should not introduce new security problems, as the code is
anyway gated by CAP_SYS_ADMIN. The device-mapper core, not the calling
task, is the legitimate owner of this long-lived file.&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;dm: avoid leaking the caller&amp;#39;s thread keyring via the table device file&lt;/p&gt;
&lt;p&gt;The refactoring in commit a28d893eb327 (&amp;#34;md: port block device access to file&amp;#34;)
accidentally causes the caller&amp;#39;s thread keyring to be kept alive long
beyond the caller&amp;#39;s lifetime.&lt;/p&gt;
&lt;p&gt;As a result, &amp;#34;cryptsetup luksSuspend&amp;#34; silently fails to wipe the
LUKS volume key from memory.&lt;/p&gt;
&lt;p&gt;In detail: &amp;#34;cryptsetup luksOpen&amp;#34; uses its supposedly ephemeral thread
keyring to pass the volume key to the kernel. dm-crypt&amp;#39;s
crypt_set_keyring_key() copies the key material into its own
crypt_config structure and then drops its own reference to the key in
the keyring with key_put().&lt;/p&gt;
&lt;p&gt;With this fix, restoring pre-v6.9 behavior, the copy in the thread
keyring is then promptly garbage collected, such that exactly one copy
of the volume key remains. This single copy is correctly wiped from
memory on &amp;#34;cryptsetup luksSuspend&amp;#34;.&lt;/p&gt;
&lt;p&gt;Without this fix, the thread keyring and the volume key in it remains.
This second copy is only freed on &amp;#34;luksClose&amp;#34;. &amp;#34;luksSuspend&amp;#34; neither
knows about this copy nor has any way to remove it, so the key remains
recoverable from RAM after a suspend that is documented to have wiped it.&lt;/p&gt;
&lt;p&gt;This fix should not introduce new security problems, as the code is
anyway gated by CAP_SYS_ADMIN. The device-mapper core, not the calling
task, is the legitimate owner of this long-lived file.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cve-2026-72103</guid>
    </item>
    <item>
      <title>USN-8887-1 — linux, linux-aws, linux-gcp, linux-gke, linux-ibm, linux-oracle, linux-realtime vulnerabilities</title>
      <link>https://cve.radiocsirt.org/vuln/usn-8887-1</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:26.04:LTS: linux, Ubuntu:26.04:LTS: linux-aws, Ubuntu:26.04:LTS: linux-gcp, Ubuntu:26.04:LTS: linux-gke, Ubuntu:26.04:LTS: linux-ibm, Ubuntu:26.04:LTS: linux-oracle, Ubuntu:26.04:LTS: linux-realtime&lt;/p&gt;
&lt;p&gt;It was discovered that some AMD processors did not properly perform Reverse
Map Table (RMP) checks when the IOMMU accessed certain host buffers. A
local attacker with hypervisor access could possibly use this to trigger an
out-of-bounds condition and compromise the integrity of SEV-SNP guest
memory. (CVE-2023-20585)&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;
  - NVDIMM (Non-Volatile Memory Device) drivers;
  - Handshake API;
  - ARM32 architecture;
  - MIPS architecture;
  - OpenRISC architecture;
  - PowerPC architecture;
  - RISC-V architecture;
  - S390 architecture;
  - x86 architecture;
  - Cryptographic API;
  - Compute Acceleration Framework;
  - Intel NPU Driver;
  - ACPI drivers;
  - Android drivers;
  - Serial ATA and Parallel ATA drivers;
  - Drivers core;
  - Rados block device (RBD) driver;
  - Ublk userspace block driver;
  - Bluetooth drivers;
  - Cdrom driver;
  - Character device driver;
  - TPM device driver;
  - Data acquisition framework and drivers;
  - Hardware crypto device drivers;
  - CXL (Compute Express Link) drivers;
  - DAX dirext access to differentiated memory framework;
  - DIBS (Direct Internal Buffer Sharing) drivers;
  - Buffer Sharing and Synchronization framework;
  - DMA engine subsystem;
  - DPLL subsystem;
  - EDAC drivers;
  - FireWire subsystem;
  - Arm Firmware Framework fo…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:26.04:LTS: linux, Ubuntu:26.04:LTS: linux-aws, Ubuntu:26.04:LTS: linux-gcp, Ubuntu:26.04:LTS: linux-gke, Ubuntu:26.04:LTS: linux-ibm, Ubuntu:26.04:LTS: linux-oracle, Ubuntu:26.04:LTS: linux-realtime&lt;/p&gt;
&lt;p&gt;It was discovered that some AMD processors did not properly perform Reverse
Map Table (RMP) checks when the IOMMU accessed certain host buffers. A
local attacker with hypervisor access could possibly use this to trigger an
out-of-bounds condition and compromise the integrity of SEV-SNP guest
memory. (CVE-2023-20585)&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;
  - NVDIMM (Non-Volatile Memory Device) drivers;
  - Handshake API;
  - ARM32 architecture;
  - MIPS architecture;
  - OpenRISC architecture;
  - PowerPC architecture;
  - RISC-V architecture;
  - S390 architecture;
  - x86 architecture;
  - Cryptographic API;
  - Compute Acceleration Framework;
  - Intel NPU Driver;
  - ACPI drivers;
  - Android drivers;
  - Serial ATA and Parallel ATA drivers;
  - Drivers core;
  - Rados block device (RBD) driver;
  - Ublk userspace block driver;
  - Bluetooth drivers;
  - Cdrom driver;
  - Character device driver;
  - TPM device driver;
  - Data acquisition framework and drivers;
  - Hardware crypto device drivers;
  - CXL (Compute Express Link) drivers;
  - DAX dirext access to differentiated memory framework;
  - DIBS (Direct Internal Buffer Sharing) drivers;
  - Buffer Sharing and Synchronization framework;
  - DMA engine subsystem;
  - DPLL subsystem;
  - EDAC drivers;
  - FireWire subsystem;
  - Arm Firmware Framework fo…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/usn-8887-1</guid>
    </item>
  </channel>
</rss>
