<?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>Fri, 02 Oct 2026 18:53:49 +0000</lastBuildDate>
    <item>
      <title>ALSA-2026:53330 — Important: kernel security, bug fix, and enhancement update</title>
      <link>https://cve.radiocsirt.org/vuln/alsa-2026:53330</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; AlmaLinux:10: kernel, AlmaLinux:10: kernel-64k, AlmaLinux:10: kernel-64k-core, AlmaLinux:10: kernel-64k-debug, AlmaLinux:10: kernel-64k-debug-core, AlmaLinux:10: kernel-64k-debug-devel, AlmaLinux:10: kernel-64k-debug-devel-matched, AlmaLinux:10: kernel-64k-debug-modules, AlmaLinux:10: kernel-64k-debug-modules-core, AlmaLinux:10: kernel-64k-debug-modules-extra and 65 more&lt;/p&gt;
&lt;p&gt;The kernel packages contain the Linux kernel, the core of any Linux operating system.&lt;/p&gt;
&lt;p&gt;Security Fix(es):&lt;/p&gt;
&lt;p&gt;* kernel: fsnotify: Fix ordering of iput() and watched_objects decrement (CVE-2024-53143)
  * kernel: shmem: fix recovery on rename failures (CVE-2025-71072)
  * kernel: futex: Fix UaF between futex_key_to_node_opt() and vma_replace_policy() (CVE-2026-23415)
  * kernel: drm/amd/display: Do not skip unrelated mode changes in DSC validation (CVE-2026-31488)
  * kernel: ipc: limit next_id allocation to the valid ID range (CVE-2026-52923)
  * kernel: mm/slab: do not limit zeroing to orig_size when only red zoning is enabled (CVE-2026-64368)
  * kernel: net: openvswitch: reject oversized nested action attrs (CVE-2026-64531)&lt;/p&gt;
&lt;p&gt;Bug Fix(es) and Enhancement(s):&lt;/p&gt;
&lt;p&gt;* Kernel oops after increasing max number of mac addresses of a mlx5 VF [almalinux-10.2.z] (JIRA:AlmaLinux-213035)
  * AlmaLinux10.0 - s390/pkey: Check length in PKEY_VERIFYPROTK ioctl [almalinux-10.2.z] (JIRA:AlmaLinux-222503)
  * AlmaLinux10.0 - s390/pkey: Check length in pkey_pckmo handler implementation [almalinux-10.2.z] (JIRA:AlmaLinux-222505)&lt;/p&gt;
&lt;p&gt;For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; AlmaLinux:10: kernel, AlmaLinux:10: kernel-64k, AlmaLinux:10: kernel-64k-core, AlmaLinux:10: kernel-64k-debug, AlmaLinux:10: kernel-64k-debug-core, AlmaLinux:10: kernel-64k-debug-devel, AlmaLinux:10: kernel-64k-debug-devel-matched, AlmaLinux:10: kernel-64k-debug-modules, AlmaLinux:10: kernel-64k-debug-modules-core, AlmaLinux:10: kernel-64k-debug-modules-extra and 65 more&lt;/p&gt;
&lt;p&gt;The kernel packages contain the Linux kernel, the core of any Linux operating system.&lt;/p&gt;
&lt;p&gt;Security Fix(es):&lt;/p&gt;
&lt;p&gt;* kernel: fsnotify: Fix ordering of iput() and watched_objects decrement (CVE-2024-53143)
  * kernel: shmem: fix recovery on rename failures (CVE-2025-71072)
  * kernel: futex: Fix UaF between futex_key_to_node_opt() and vma_replace_policy() (CVE-2026-23415)
  * kernel: drm/amd/display: Do not skip unrelated mode changes in DSC validation (CVE-2026-31488)
  * kernel: ipc: limit next_id allocation to the valid ID range (CVE-2026-52923)
  * kernel: mm/slab: do not limit zeroing to orig_size when only red zoning is enabled (CVE-2026-64368)
  * kernel: net: openvswitch: reject oversized nested action attrs (CVE-2026-64531)&lt;/p&gt;
&lt;p&gt;Bug Fix(es) and Enhancement(s):&lt;/p&gt;
&lt;p&gt;* Kernel oops after increasing max number of mac addresses of a mlx5 VF [almalinux-10.2.z] (JIRA:AlmaLinux-213035)
  * AlmaLinux10.0 - s390/pkey: Check length in PKEY_VERIFYPROTK ioctl [almalinux-10.2.z] (JIRA:AlmaLinux-222503)
  * AlmaLinux10.0 - s390/pkey: Check length in pkey_pckmo handler implementation [almalinux-10.2.z] (JIRA:AlmaLinux-222505)&lt;/p&gt;
&lt;p&gt;For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/alsa-2026:53330</guid>
    </item>
    <item>
      <title>bdu:2026-11991</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-11991</link>
      <description>bdu:2026-11991</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-11991</guid>
    </item>
    <item>
      <title>BELL-CVE-2025-71072</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2025-71072</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2025-71072</guid>
    </item>
    <item>
      <title>certfr-2026-avi-0166 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian. Elles permettent à un attaquant de provo…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-0166</link>
      <description>certfr-2026-avi-0166</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-0166</guid>
    </item>
    <item>
      <title>EUVD-2026-347536</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-347536</link>
      <description>EUVD-2026-347536</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-347536</guid>
    </item>
    <item>
      <title>fkie_cve-2025-71072</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2025-71072</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;shmem: fix recovery on rename failures&lt;/p&gt;
&lt;p&gt;maple_tree insertions can fail if we are seriously short on memory;
simple_offset_rename() does not recover well if it runs into that.
The same goes for simple_offset_rename_exchange().&lt;/p&gt;
&lt;p&gt;Moreover, shmem_whiteout() expects that if it succeeds, the caller will
progress to d_move(), i.e. that shmem_rename2() won&amp;#39;t fail past the
successful call of shmem_whiteout().&lt;/p&gt;
&lt;p&gt;Not hard to fix, fortunately - mtree_store() can&amp;#39;t fail if the index we
are trying to store into is already present in the tree as a singleton.&lt;/p&gt;
&lt;p&gt;For simple_offset_rename_exchange() that&amp;#39;s enough - we just need to be
careful about the order of operations.&lt;/p&gt;
&lt;p&gt;For simple_offset_rename() solution is to preinsert the target into the
tree for new_dir; the rest can be done without any potentially failing
operations.&lt;/p&gt;
&lt;p&gt;That preinsertion has to be done in shmem_rename2() rather than in
simple_offset_rename() itself - otherwise we&amp;#39;d need to deal with the
possibility of failure after successful shmem_whiteout().&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;shmem: fix recovery on rename failures&lt;/p&gt;
&lt;p&gt;maple_tree insertions can fail if we are seriously short on memory;
simple_offset_rename() does not recover well if it runs into that.
The same goes for simple_offset_rename_exchange().&lt;/p&gt;
&lt;p&gt;Moreover, shmem_whiteout() expects that if it succeeds, the caller will
progress to d_move(), i.e. that shmem_rename2() won&amp;#39;t fail past the
successful call of shmem_whiteout().&lt;/p&gt;
&lt;p&gt;Not hard to fix, fortunately - mtree_store() can&amp;#39;t fail if the index we
are trying to store into is already present in the tree as a singleton.&lt;/p&gt;
&lt;p&gt;For simple_offset_rename_exchange() that&amp;#39;s enough - we just need to be
careful about the order of operations.&lt;/p&gt;
&lt;p&gt;For simple_offset_rename() solution is to preinsert the target into the
tree for new_dir; the rest can be done without any potentially failing
operations.&lt;/p&gt;
&lt;p&gt;That preinsertion has to be done in shmem_rename2() rather than in
simple_offset_rename() itself - otherwise we&amp;#39;d need to deal with the
possibility of failure after successful shmem_whiteout().&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2025-71072</guid>
    </item>
    <item>
      <title>GHSA-2j2j-fmxq-39xm</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-2j2j-fmxq-39xm</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;shmem: fix recovery on rename failures&lt;/p&gt;
&lt;p&gt;maple_tree insertions can fail if we are seriously short on memory;
simple_offset_rename() does not recover well if it runs into that.
The same goes for simple_offset_rename_exchange().&lt;/p&gt;
&lt;p&gt;Moreover, shmem_whiteout() expects that if it succeeds, the caller will
progress to d_move(), i.e. that shmem_rename2() won&amp;#39;t fail past the
successful call of shmem_whiteout().&lt;/p&gt;
&lt;p&gt;Not hard to fix, fortunately - mtree_store() can&amp;#39;t fail if the index we
are trying to store into is already present in the tree as a singleton.&lt;/p&gt;
&lt;p&gt;For simple_offset_rename_exchange() that&amp;#39;s enough - we just need to be
careful about the order of operations.&lt;/p&gt;
&lt;p&gt;For simple_offset_rename() solution is to preinsert the target into the
tree for new_dir; the rest can be done without any potentially failing
operations.&lt;/p&gt;
&lt;p&gt;That preinsertion has to be done in shmem_rename2() rather than in
simple_offset_rename() itself - otherwise we&amp;#39;d need to deal with the
possibility of failure after successful shmem_whiteout().&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;shmem: fix recovery on rename failures&lt;/p&gt;
&lt;p&gt;maple_tree insertions can fail if we are seriously short on memory;
simple_offset_rename() does not recover well if it runs into that.
The same goes for simple_offset_rename_exchange().&lt;/p&gt;
&lt;p&gt;Moreover, shmem_whiteout() expects that if it succeeds, the caller will
progress to d_move(), i.e. that shmem_rename2() won&amp;#39;t fail past the
successful call of shmem_whiteout().&lt;/p&gt;
&lt;p&gt;Not hard to fix, fortunately - mtree_store() can&amp;#39;t fail if the index we
are trying to store into is already present in the tree as a singleton.&lt;/p&gt;
&lt;p&gt;For simple_offset_rename_exchange() that&amp;#39;s enough - we just need to be
careful about the order of operations.&lt;/p&gt;
&lt;p&gt;For simple_offset_rename() solution is to preinsert the target into the
tree for new_dir; the rest can be done without any potentially failing
operations.&lt;/p&gt;
&lt;p&gt;That preinsertion has to be done in shmem_rename2() rather than in
simple_offset_rename() itself - otherwise we&amp;#39;d need to deal with the
possibility of failure after successful shmem_whiteout().&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-2j2j-fmxq-39xm</guid>
    </item>
    <item>
      <title>msrc_CVE-2025-71072 — shmem: fix recovery on rename failures</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2025-71072</link>
      <description>msrc_CVE-2025-71072</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2025-71072</guid>
    </item>
    <item>
      <title>OESA-2026-1759 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2026-1759</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:24.03-LTS: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;iommu/s390: Implement blocking domain&lt;/p&gt;
&lt;p&gt;This fixes a crash when surprise hot-unplugging a PCI device. This crash
happens because during hot-unplug __iommu_group_set_domain_nofail()
attaching the default domain fails when the platform no longer
recognizes the device as it has already been removed and we end up with
a NULL domain pointer and UAF. This is exactly the case referred to in
the second comment in __iommu_device_set_domain() and just as stated
there if we can instead attach the blocking domain the UAF is prevented
as this can handle the already removed device. Implement the blocking
domain to use this handling.  With this change, the crash is fixed but
we still hit a warning attempting to change DMA ownership on a blocked
device.(CVE-2024-53232)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;iommu: Fix two issues in iommu_copy_struct_from_user()&lt;/p&gt;
&lt;p&gt;In the review for iommu_copy_struct_to_user() helper, Matt pointed out that
a NULL pointer should be rejected prior to dereferencing it:
https://lore.kernel.org/all/(CVE-2025-37900)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;smb: client: Avoid race in open_cached_dir with lease breaks&lt;/p&gt;
&lt;p&gt;A pre-existing valid cfid returned from find_or_create_cached_dir might
race with a lease break, meaning open_cached_dir doesn&amp;amp;apos;t consider it
valid,…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:24.03-LTS: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;iommu/s390: Implement blocking domain&lt;/p&gt;
&lt;p&gt;This fixes a crash when surprise hot-unplugging a PCI device. This crash
happens because during hot-unplug __iommu_group_set_domain_nofail()
attaching the default domain fails when the platform no longer
recognizes the device as it has already been removed and we end up with
a NULL domain pointer and UAF. This is exactly the case referred to in
the second comment in __iommu_device_set_domain() and just as stated
there if we can instead attach the blocking domain the UAF is prevented
as this can handle the already removed device. Implement the blocking
domain to use this handling.  With this change, the crash is fixed but
we still hit a warning attempting to change DMA ownership on a blocked
device.(CVE-2024-53232)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;iommu: Fix two issues in iommu_copy_struct_from_user()&lt;/p&gt;
&lt;p&gt;In the review for iommu_copy_struct_to_user() helper, Matt pointed out that
a NULL pointer should be rejected prior to dereferencing it:
https://lore.kernel.org/all/(CVE-2025-37900)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;smb: client: Avoid race in open_cached_dir with lease breaks&lt;/p&gt;
&lt;p&gt;A pre-existing valid cfid returned from find_or_create_cached_dir might
race with a lease break, meaning open_cached_dir doesn&amp;amp;apos;t consider it
valid,…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2026-1759</guid>
    </item>
    <item>
      <title>RHSA-2026:53330 — Red Hat Security Advisory: kernel security, bug fix, and enhancement update</title>
      <link>https://cve.radiocsirt.org/vuln/rhsa-2026:53330</link>
      <description>&lt;p&gt;kernel: fsnotify: Fix ordering of iput() and watched_objects decrement kernel: shmem: fix recovery on rename failures kernel: futex: Fix UaF between futex_key_to_node_opt() and vma_replace_policy() kernel: drm/amd/display: Do not skip unrelated mode changes in DSC validation kernel: ipc: limit next_id allocation to the valid ID range kernel: mm/slab: do not limit zeroing to orig_size when only red zoning is enabled kernel: net: openvswitch: reject oversized nested action attrs&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel: fsnotify: Fix ordering of iput() and watched_objects decrement kernel: shmem: fix recovery on rename failures kernel: futex: Fix UaF between futex_key_to_node_opt() and vma_replace_policy() kernel: drm/amd/display: Do not skip unrelated mode changes in DSC validation kernel: ipc: limit next_id allocation to the valid ID range kernel: mm/slab: do not limit zeroing to orig_size when only red zoning is enabled kernel: net: openvswitch: reject oversized nested action attrs&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rhsa-2026:53330</guid>
    </item>
    <item>
      <title>RLSA-2026:53330 — Important: kernel security, bug fix, and enhancement update</title>
      <link>https://cve.radiocsirt.org/vuln/rlsa-2026:53330</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Rocky Linux:10: kernel&lt;/p&gt;
&lt;p&gt;The kernel packages contain the Linux kernel, the core of any Linux operating system.&lt;/p&gt;
&lt;p&gt;Security Fix(es):&lt;/p&gt;
&lt;p&gt;* kernel: fsnotify: Fix ordering of iput() and watched_objects decrement (CVE-2024-53143)&lt;/p&gt;
&lt;p&gt;* kernel: shmem: fix recovery on rename failures (CVE-2025-71072)&lt;/p&gt;
&lt;p&gt;* kernel: futex: Fix UaF between futex_key_to_node_opt() and vma_replace_policy() (CVE-2026-23415)&lt;/p&gt;
&lt;p&gt;* kernel: drm/amd/display: Do not skip unrelated mode changes in DSC validation (CVE-2026-31488)&lt;/p&gt;
&lt;p&gt;* kernel: ipc: limit next_id allocation to the valid ID range (CVE-2026-52923)&lt;/p&gt;
&lt;p&gt;* kernel: mm/slab: do not limit zeroing to orig_size when only red zoning is enabled (CVE-2026-64368)&lt;/p&gt;
&lt;p&gt;* kernel: net: openvswitch: reject oversized nested action attrs (CVE-2026-64531)&lt;/p&gt;
&lt;p&gt;Bug Fix(es) and Enhancement(s):&lt;/p&gt;
&lt;p&gt;* Kernel oops after increasing max number of mac addresses of a mlx5 VF [rhel-10.2.z] (JIRA:Rocky Linux-213035)&lt;/p&gt;
&lt;p&gt;* Rocky Linux10.0 - s390/pkey: Check length in PKEY_VERIFYPROTK ioctl [rhel-10.2.z] (JIRA:Rocky Linux-222503)&lt;/p&gt;
&lt;p&gt;* Rocky Linux10.0 - s390/pkey: Check length in pkey_pckmo handler implementation [rhel-10.2.z] (JIRA:Rocky Linux-222505)&lt;/p&gt;
&lt;p&gt;For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Rocky Linux:10: kernel&lt;/p&gt;
&lt;p&gt;The kernel packages contain the Linux kernel, the core of any Linux operating system.&lt;/p&gt;
&lt;p&gt;Security Fix(es):&lt;/p&gt;
&lt;p&gt;* kernel: fsnotify: Fix ordering of iput() and watched_objects decrement (CVE-2024-53143)&lt;/p&gt;
&lt;p&gt;* kernel: shmem: fix recovery on rename failures (CVE-2025-71072)&lt;/p&gt;
&lt;p&gt;* kernel: futex: Fix UaF between futex_key_to_node_opt() and vma_replace_policy() (CVE-2026-23415)&lt;/p&gt;
&lt;p&gt;* kernel: drm/amd/display: Do not skip unrelated mode changes in DSC validation (CVE-2026-31488)&lt;/p&gt;
&lt;p&gt;* kernel: ipc: limit next_id allocation to the valid ID range (CVE-2026-52923)&lt;/p&gt;
&lt;p&gt;* kernel: mm/slab: do not limit zeroing to orig_size when only red zoning is enabled (CVE-2026-64368)&lt;/p&gt;
&lt;p&gt;* kernel: net: openvswitch: reject oversized nested action attrs (CVE-2026-64531)&lt;/p&gt;
&lt;p&gt;Bug Fix(es) and Enhancement(s):&lt;/p&gt;
&lt;p&gt;* Kernel oops after increasing max number of mac addresses of a mlx5 VF [rhel-10.2.z] (JIRA:Rocky Linux-213035)&lt;/p&gt;
&lt;p&gt;* Rocky Linux10.0 - s390/pkey: Check length in PKEY_VERIFYPROTK ioctl [rhel-10.2.z] (JIRA:Rocky Linux-222503)&lt;/p&gt;
&lt;p&gt;* Rocky Linux10.0 - s390/pkey: Check length in pkey_pckmo handler implementation [rhel-10.2.z] (JIRA:Rocky Linux-222505)&lt;/p&gt;
&lt;p&gt;For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rlsa-2026:53330</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2025-71072</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-71072</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 140 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: shmem: fix recovery on rename failures maple_tree insertions can fail if we are seriously short on memory; simple_offset_rename() does not recover well if it runs into that. The same goes for simple_offset_rename_exchange(). Moreover, shmem_whiteout() expects that if it succeeds, the caller will progress to d_move(), i.e. that shmem_rename2() won&amp;#39;t fail past the successful call of shmem_whiteout(). Not hard to fix, fortunately - mtree_store() can&amp;#39;t fail if the index we are trying to store into is already present in the tree as a singleton. For simple_offset_rename_exchange() that&amp;#39;s enough - we just need to be careful about the order of operations. For simple_offset_rename() solution is to preinsert the target into the tree for new_dir; the rest can be done without any potentially failing operations. That preinsertion has to be done in shmem_rename2() rather than in simple_offset_rename() itself - otherwise we&amp;#39;d need to deal with the possibility of failure after successful shmem_whiteout().&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 140 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: shmem: fix recovery on rename failures maple_tree insertions can fail if we are seriously short on memory; simple_offset_rename() does not recover well if it runs into that. The same goes for simple_offset_rename_exchange(). Moreover, shmem_whiteout() expects that if it succeeds, the caller will progress to d_move(), i.e. that shmem_rename2() won&amp;#39;t fail past the successful call of shmem_whiteout(). Not hard to fix, fortunately - mtree_store() can&amp;#39;t fail if the index we are trying to store into is already present in the tree as a singleton. For simple_offset_rename_exchange() that&amp;#39;s enough - we just need to be careful about the order of operations. For simple_offset_rename() solution is to preinsert the target into the tree for new_dir; the rest can be done without any potentially failing operations. That preinsertion has to be done in shmem_rename2() rather than in simple_offset_rename() itself - otherwise we&amp;#39;d need to deal with the possibility of failure after successful shmem_whiteout().&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-71072</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-0086 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0086</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen um nicht näher spezifizierte Angriffe durchzuführen, die möglicherweise zu einer Denial-of-Service- Bedingung führen oder eine Speicherbeschädigung verursachen können.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen um nicht näher spezifizierte Angriffe durchzuführen, die möglicherweise zu einer Denial-of-Service- Bedingung führen oder eine Speicherbeschädigung verursachen können.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0086</guid>
    </item>
  </channel>
</rss>
