<?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>Sun, 04 Oct 2026 01:29:37 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-03367</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-03367</link>
      <description>bdu:2026-03367</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-03367</guid>
    </item>
    <item>
      <title>BELL-CVE-2025-39927</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2025-39927</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, 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:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2025-39927</guid>
    </item>
    <item>
      <title>certfr-2026-avi-0247 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de SUSE. Certaines d'entre elles permettent à un at…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-0247</link>
      <description>certfr-2026-avi-0247</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-0247</guid>
    </item>
    <item>
      <title>EUVD-2026-347252</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-347252</link>
      <description>EUVD-2026-347252</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-347252</guid>
    </item>
    <item>
      <title>fkie_cve-2025-39927</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2025-39927</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ceph: fix race condition validating r_parent before applying state&lt;/p&gt;
&lt;p&gt;Add validation to ensure the cached parent directory inode matches the
directory info in MDS replies. This prevents client-side race conditions
where concurrent operations (e.g. rename) cause r_parent to become stale
between request initiation and reply processing, which could lead to
applying state changes to incorrect directory inodes.&lt;/p&gt;
&lt;p&gt;[ idryomov: folded a kerneldoc fixup and a follow-up fix from Alex to
  move CEPH_CAP_PIN reference when r_parent is updated:&lt;/p&gt;
&lt;p&gt;When the parent directory lock is not held, req-&amp;gt;r_parent can become
  stale and is updated to point to the correct inode.  However, the
  associated CEPH_CAP_PIN reference was not being adjusted.  The
  CEPH_CAP_PIN is a reference on an inode that is tracked for
  accounting purposes.  Moving this pin is important to keep the
  accounting balanced. When the pin was not moved from the old parent
  to the new one, it created two problems: The reference on the old,
  stale parent was never released, causing a reference leak.
  A reference for the new parent was never acquired, creating the risk
  of a reference underflow later in ceph_mdsc_release_request().  This
  patch corrects the logic by releasing the pin from the old parent and
  acquiring it for the new parent when r_parent is switched.  This
  ensures reference accounting stays balanced. ]&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;ceph: fix race condition validating r_parent before applying state&lt;/p&gt;
&lt;p&gt;Add validation to ensure the cached parent directory inode matches the
directory info in MDS replies. This prevents client-side race conditions
where concurrent operations (e.g. rename) cause r_parent to become stale
between request initiation and reply processing, which could lead to
applying state changes to incorrect directory inodes.&lt;/p&gt;
&lt;p&gt;[ idryomov: folded a kerneldoc fixup and a follow-up fix from Alex to
  move CEPH_CAP_PIN reference when r_parent is updated:&lt;/p&gt;
&lt;p&gt;When the parent directory lock is not held, req-&amp;gt;r_parent can become
  stale and is updated to point to the correct inode.  However, the
  associated CEPH_CAP_PIN reference was not being adjusted.  The
  CEPH_CAP_PIN is a reference on an inode that is tracked for
  accounting purposes.  Moving this pin is important to keep the
  accounting balanced. When the pin was not moved from the old parent
  to the new one, it created two problems: The reference on the old,
  stale parent was never released, causing a reference leak.
  A reference for the new parent was never acquired, creating the risk
  of a reference underflow later in ceph_mdsc_release_request().  This
  patch corrects the logic by releasing the pin from the old parent and
  acquiring it for the new parent when r_parent is switched.  This
  ensures reference accounting stays balanced. ]&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2025-39927</guid>
    </item>
    <item>
      <title>GHSA-7jh2-8xqp-qc8p</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-7jh2-8xqp-qc8p</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ceph: fix race condition validating r_parent before applying state&lt;/p&gt;
&lt;p&gt;Add validation to ensure the cached parent directory inode matches the
directory info in MDS replies. This prevents client-side race conditions
where concurrent operations (e.g. rename) cause r_parent to become stale
between request initiation and reply processing, which could lead to
applying state changes to incorrect directory inodes.&lt;/p&gt;
&lt;p&gt;[ idryomov: folded a kerneldoc fixup and a follow-up fix from Alex to
  move CEPH_CAP_PIN reference when r_parent is updated:&lt;/p&gt;
&lt;p&gt;When the parent directory lock is not held, req-&amp;gt;r_parent can become
  stale and is updated to point to the correct inode.  However, the
  associated CEPH_CAP_PIN reference was not being adjusted.  The
  CEPH_CAP_PIN is a reference on an inode that is tracked for
  accounting purposes.  Moving this pin is important to keep the
  accounting balanced. When the pin was not moved from the old parent
  to the new one, it created two problems: The reference on the old,
  stale parent was never released, causing a reference leak.
  A reference for the new parent was never acquired, creating the risk
  of a reference underflow later in ceph_mdsc_release_request().  This
  patch corrects the logic by releasing the pin from the old parent and
  acquiring it for the new parent when r_parent is switched.  This
  ensures reference accounting stays balanced. ]&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;ceph: fix race condition validating r_parent before applying state&lt;/p&gt;
&lt;p&gt;Add validation to ensure the cached parent directory inode matches the
directory info in MDS replies. This prevents client-side race conditions
where concurrent operations (e.g. rename) cause r_parent to become stale
between request initiation and reply processing, which could lead to
applying state changes to incorrect directory inodes.&lt;/p&gt;
&lt;p&gt;[ idryomov: folded a kerneldoc fixup and a follow-up fix from Alex to
  move CEPH_CAP_PIN reference when r_parent is updated:&lt;/p&gt;
&lt;p&gt;When the parent directory lock is not held, req-&amp;gt;r_parent can become
  stale and is updated to point to the correct inode.  However, the
  associated CEPH_CAP_PIN reference was not being adjusted.  The
  CEPH_CAP_PIN is a reference on an inode that is tracked for
  accounting purposes.  Moving this pin is important to keep the
  accounting balanced. When the pin was not moved from the old parent
  to the new one, it created two problems: The reference on the old,
  stale parent was never released, causing a reference leak.
  A reference for the new parent was never acquired, creating the risk
  of a reference underflow later in ceph_mdsc_release_request().  This
  patch corrects the logic by releasing the pin from the old parent and
  acquiring it for the new parent when r_parent is switched.  This
  ensures reference accounting stays balanced. ]&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-7jh2-8xqp-qc8p</guid>
    </item>
    <item>
      <title>msrc_CVE-2025-39927 — ceph: fix race condition validating r_parent before applying state</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2025-39927</link>
      <description>msrc_CVE-2025-39927</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2025-39927</guid>
    </item>
    <item>
      <title>OESA-2026-1303 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2026-1303</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;ptr_ring: do not block hard interrupts in ptr_ring_resize_multiple()&lt;/p&gt;
&lt;p&gt;Jakub added a lockdep_assert_no_hardirq() check in __page_pool_put_page()
to increase test coverage.&lt;/p&gt;
&lt;p&gt;syzbot found a splat caused by hard irq blocking in
ptr_ring_resize_multiple() [1]&lt;/p&gt;
&lt;p&gt;As current users of ptr_ring_resize_multiple() do not require
hard irqs being masked, replace it to only block BH.&lt;/p&gt;
&lt;p&gt;Rename helpers to better reflect they are safe against BH only.&lt;/p&gt;
&lt;p&gt;- ptr_ring_resize_multiple() to ptr_ring_resize_multiple_bh()
- skb_array_resize_multiple() to skb_array_resize_multiple_bh()&lt;/p&gt;
&lt;p&gt;[1]&lt;/p&gt;
&lt;p&gt;WARNING: CPU: 1 PID: 9150 at net/core/page_pool.c:709 __page_pool_put_page net/core/page_pool.c:709 [inline]
WARNING: CPU: 1 PID: 9150 at net/core/page_pool.c:709 page_pool_put_unrefed_netmem+0x157/0xa40 net/core/page_pool.c:780
Modules linked in:
CPU: 1 UID: 0 PID: 9150 Comm: syz.1.1052 Not tainted 6.11.0-rc3-syzkaller-00202-gf8669d7b5f5d #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
RIP: 0010:__page_pool_put_page net/core/page_pool.c:709 [inline]
RIP: 0010:page_pool_put_unrefed_netmem+0x157/0xa40 net/core/page_pool.c:780
Code: 74 0e e8 7c aa fb f7 eb 43 e8 75 aa fb f7 eb 3c 65 8b 1d 38 a8 6a 76 31 ff 89 de e8 a3 ae fb f7 85 db 74 0b e8 5a aa fb f7 90 &amp;amp;lt;0f&amp;amp;gt; 0b 90 eb 1d 65 8b 1d 15 a8 6a 76 31 ff 89 de e8 84 ae fb f7 85
RSP:…&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;ptr_ring: do not block hard interrupts in ptr_ring_resize_multiple()&lt;/p&gt;
&lt;p&gt;Jakub added a lockdep_assert_no_hardirq() check in __page_pool_put_page()
to increase test coverage.&lt;/p&gt;
&lt;p&gt;syzbot found a splat caused by hard irq blocking in
ptr_ring_resize_multiple() [1]&lt;/p&gt;
&lt;p&gt;As current users of ptr_ring_resize_multiple() do not require
hard irqs being masked, replace it to only block BH.&lt;/p&gt;
&lt;p&gt;Rename helpers to better reflect they are safe against BH only.&lt;/p&gt;
&lt;p&gt;- ptr_ring_resize_multiple() to ptr_ring_resize_multiple_bh()
- skb_array_resize_multiple() to skb_array_resize_multiple_bh()&lt;/p&gt;
&lt;p&gt;[1]&lt;/p&gt;
&lt;p&gt;WARNING: CPU: 1 PID: 9150 at net/core/page_pool.c:709 __page_pool_put_page net/core/page_pool.c:709 [inline]
WARNING: CPU: 1 PID: 9150 at net/core/page_pool.c:709 page_pool_put_unrefed_netmem+0x157/0xa40 net/core/page_pool.c:780
Modules linked in:
CPU: 1 UID: 0 PID: 9150 Comm: syz.1.1052 Not tainted 6.11.0-rc3-syzkaller-00202-gf8669d7b5f5d #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
RIP: 0010:__page_pool_put_page net/core/page_pool.c:709 [inline]
RIP: 0010:page_pool_put_unrefed_netmem+0x157/0xa40 net/core/page_pool.c:780
Code: 74 0e e8 7c aa fb f7 eb 43 e8 75 aa fb f7 eb 3c 65 8b 1d 38 a8 6a 76 31 ff 89 de e8 a3 ae fb f7 85 db 74 0b e8 5a aa fb f7 90 &amp;amp;lt;0f&amp;amp;gt; 0b 90 eb 1d 65 8b 1d 15 a8 6a 76 31 ff 89 de e8 84 ae fb f7 85
RSP:…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2026-1303</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:20287-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:20287-1</link>
      <description>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/opensuse-su-2026:20287-1</guid>
    </item>
    <item>
      <title>RHSA-2025:17241 — Red Hat Security Advisory: kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/rhsa-2025:17241</link>
      <description>&lt;p&gt;kernel: net_sched: hfsc: Fix a potential UAF in hfsc_dequeue() too kernel: i40e: fix MMIO write access to an invalid page in i40e_clear_hw kernel: drm/gem: Acquire references on GEM handles for framebuffers kernel: netfilter: nf_conntrack: fix crash due to removal of uninitialised entry kernel: xfrm: interface: fix use-after-free after changing collect_md xfrm interface kernel: smb: client: fix use-after-free in cifs_oplock_break kernel: ceph: fix race condition validating r_parent before applying state&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel: net_sched: hfsc: Fix a potential UAF in hfsc_dequeue() too kernel: i40e: fix MMIO write access to an invalid page in i40e_clear_hw kernel: drm/gem: Acquire references on GEM handles for framebuffers kernel: netfilter: nf_conntrack: fix crash due to removal of uninitialised entry kernel: xfrm: interface: fix use-after-free after changing collect_md xfrm interface kernel: smb: client: fix use-after-free in cifs_oplock_break kernel: ceph: fix race condition validating r_parent before applying state&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rhsa-2025:17241</guid>
    </item>
    <item>
      <title>SUSE-SU-2026:20555-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2026:20555-1</link>
      <description>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/suse-su-2026:20555-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2025-39927</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-39927</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 216 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: ceph: fix race condition validating r_parent before applying state Add validation to ensure the cached parent directory inode matches the directory info in MDS replies. This prevents client-side race conditions where concurrent operations (e.g. rename) cause r_parent to become stale between request initiation and reply processing, which could lead to applying state changes to incorrect directory inodes. [ idryomov: folded a kerneldoc fixup and a follow-up fix from Alex to   move CEPH_CAP_PIN reference when r_parent is updated:   When the parent directory lock is not held, req-&amp;gt;r_parent can become   stale and is updated to point to the correct inode.  However, the   associated CEPH_CAP_PIN reference was not being adjusted.  The   CEPH_CAP_PIN is a reference on an inode that is tracked for   accounting purposes.  Moving this pin is important to keep the   accounting balanced. When the pin was not moved from the old parent   to the new one, it created two problems: The reference on the old,   stale parent was never released, causing a reference leak.   A reference for the new parent was never acquired, creating the risk   of a reference underflow later in ceph_mdsc_release_request().  This   patch corrects the logic by releasing the pin from the old parent and   acquiring it for the new parent when r_parent is switched.  This   ensures reference accounting stays balanced. ]&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 216 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: ceph: fix race condition validating r_parent before applying state Add validation to ensure the cached parent directory inode matches the directory info in MDS replies. This prevents client-side race conditions where concurrent operations (e.g. rename) cause r_parent to become stale between request initiation and reply processing, which could lead to applying state changes to incorrect directory inodes. [ idryomov: folded a kerneldoc fixup and a follow-up fix from Alex to   move CEPH_CAP_PIN reference when r_parent is updated:   When the parent directory lock is not held, req-&amp;gt;r_parent can become   stale and is updated to point to the correct inode.  However, the   associated CEPH_CAP_PIN reference was not being adjusted.  The   CEPH_CAP_PIN is a reference on an inode that is tracked for   accounting purposes.  Moving this pin is important to keep the   accounting balanced. When the pin was not moved from the old parent   to the new one, it created two problems: The reference on the old,   stale parent was never released, causing a reference leak.   A reference for the new parent was never acquired, creating the risk   of a reference underflow later in ceph_mdsc_release_request().  This   patch corrects the logic by releasing the pin from the old parent and   acquiring it for the new parent when r_parent is switched.  This   ensures reference accounting stays balanced. ]&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-39927</guid>
    </item>
    <item>
      <title>WID-SEC-W-2025-2170 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2170</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen und andere nicht näher spezifizierte Angriffe durchzuführen, möglicherweise um beliebigen Code auszuführen oder eine Speicherbeschädigung zu verursachen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen und andere nicht näher spezifizierte Angriffe durchzuführen, möglicherweise um beliebigen Code auszuführen oder eine Speicherbeschädigung zu verursachen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2170</guid>
    </item>
  </channel>
</rss>
