<?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>Sat, 03 Oct 2026 17:33:06 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-01391</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-01391</link>
      <description>bdu:2026-01391</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-01391</guid>
    </item>
    <item>
      <title>BELL-CVE-2025-37856</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2025-37856</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-37856</guid>
    </item>
    <item>
      <title>certfr-2025-avi-0559 — De multiples vulnérabilités ont été découvertes dans le noyau Linux d'Ubuntu. Certaines d'entre elles permettent à un a…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2025-avi-0559</link>
      <description>certfr-2025-avi-0559</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2025-avi-0559</guid>
    </item>
    <item>
      <title>EUVD-2026-346833</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-346833</link>
      <description>EUVD-2026-346833</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-346833</guid>
    </item>
    <item>
      <title>fkie_cve-2025-37856</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2025-37856</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;btrfs: harden block_group::bg_list against list_del() races&lt;/p&gt;
&lt;p&gt;As far as I can tell, these calls of list_del_init() on bg_list cannot
run concurrently with btrfs_mark_bg_unused() or btrfs_mark_bg_to_reclaim(),
as they are in transaction error paths and situations where the block
group is readonly.&lt;/p&gt;
&lt;p&gt;However, if there is any chance at all of racing with mark_bg_unused(),
or a different future user of bg_list, better to be safe than sorry.&lt;/p&gt;
&lt;p&gt;Otherwise we risk the following interleaving (bg_list refcount in parens)&lt;/p&gt;
&lt;p&gt;T1 (some random op)                       T2 (btrfs_mark_bg_unused)
                                        !list_empty(&amp;amp;bg-&amp;gt;bg_list); (1)
list_del_init(&amp;amp;bg-&amp;gt;bg_list); (1)
                                        list_move_tail (1)
btrfs_put_block_group (0)
                                        btrfs_delete_unused_bgs
                                             bg = list_first_entry
                                             list_del_init(&amp;amp;bg-&amp;gt;bg_list);
                                             btrfs_put_block_group(bg); (-1)&lt;/p&gt;
&lt;p&gt;Ultimately, this results in a broken ref count that hits zero one deref
early and the real final deref underflows the refcount, resulting in a WARNING.&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;btrfs: harden block_group::bg_list against list_del() races&lt;/p&gt;
&lt;p&gt;As far as I can tell, these calls of list_del_init() on bg_list cannot
run concurrently with btrfs_mark_bg_unused() or btrfs_mark_bg_to_reclaim(),
as they are in transaction error paths and situations where the block
group is readonly.&lt;/p&gt;
&lt;p&gt;However, if there is any chance at all of racing with mark_bg_unused(),
or a different future user of bg_list, better to be safe than sorry.&lt;/p&gt;
&lt;p&gt;Otherwise we risk the following interleaving (bg_list refcount in parens)&lt;/p&gt;
&lt;p&gt;T1 (some random op)                       T2 (btrfs_mark_bg_unused)
                                        !list_empty(&amp;amp;bg-&amp;gt;bg_list); (1)
list_del_init(&amp;amp;bg-&amp;gt;bg_list); (1)
                                        list_move_tail (1)
btrfs_put_block_group (0)
                                        btrfs_delete_unused_bgs
                                             bg = list_first_entry
                                             list_del_init(&amp;amp;bg-&amp;gt;bg_list);
                                             btrfs_put_block_group(bg); (-1)&lt;/p&gt;
&lt;p&gt;Ultimately, this results in a broken ref count that hits zero one deref
early and the real final deref underflows the refcount, resulting in a WARNING.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2025-37856</guid>
    </item>
    <item>
      <title>GHSA-ppp2-86mr-9vh3</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-ppp2-86mr-9vh3</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;btrfs: harden block_group::bg_list against list_del() races&lt;/p&gt;
&lt;p&gt;As far as I can tell, these calls of list_del_init() on bg_list cannot
run concurrently with btrfs_mark_bg_unused() or btrfs_mark_bg_to_reclaim(),
as they are in transaction error paths and situations where the block
group is readonly.&lt;/p&gt;
&lt;p&gt;However, if there is any chance at all of racing with mark_bg_unused(),
or a different future user of bg_list, better to be safe than sorry.&lt;/p&gt;
&lt;p&gt;Otherwise we risk the following interleaving (bg_list refcount in parens)&lt;/p&gt;
&lt;p&gt;T1 (some random op)                       T2 (btrfs_mark_bg_unused)
                                        !list_empty(&amp;amp;bg-&amp;gt;bg_list); (1)
list_del_init(&amp;amp;bg-&amp;gt;bg_list); (1)
                                        list_move_tail (1)
btrfs_put_block_group (0)
                                        btrfs_delete_unused_bgs
                                             bg = list_first_entry
                                             list_del_init(&amp;amp;bg-&amp;gt;bg_list);
                                             btrfs_put_block_group(bg); (-1)&lt;/p&gt;
&lt;p&gt;Ultimately, this results in a broken ref count that hits zero one deref
early and the real final deref underflows the refcount, resulting in a WARNING.&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;btrfs: harden block_group::bg_list against list_del() races&lt;/p&gt;
&lt;p&gt;As far as I can tell, these calls of list_del_init() on bg_list cannot
run concurrently with btrfs_mark_bg_unused() or btrfs_mark_bg_to_reclaim(),
as they are in transaction error paths and situations where the block
group is readonly.&lt;/p&gt;
&lt;p&gt;However, if there is any chance at all of racing with mark_bg_unused(),
or a different future user of bg_list, better to be safe than sorry.&lt;/p&gt;
&lt;p&gt;Otherwise we risk the following interleaving (bg_list refcount in parens)&lt;/p&gt;
&lt;p&gt;T1 (some random op)                       T2 (btrfs_mark_bg_unused)
                                        !list_empty(&amp;amp;bg-&amp;gt;bg_list); (1)
list_del_init(&amp;amp;bg-&amp;gt;bg_list); (1)
                                        list_move_tail (1)
btrfs_put_block_group (0)
                                        btrfs_delete_unused_bgs
                                             bg = list_first_entry
                                             list_del_init(&amp;amp;bg-&amp;gt;bg_list);
                                             btrfs_put_block_group(bg); (-1)&lt;/p&gt;
&lt;p&gt;Ultimately, this results in a broken ref count that hits zero one deref
early and the real final deref underflows the refcount, resulting in a WARNING.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-ppp2-86mr-9vh3</guid>
    </item>
    <item>
      <title>msrc_CVE-2025-37856 — btrfs: harden block_group::bg_list against list_del() races</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2025-37856</link>
      <description>msrc_CVE-2025-37856</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2025-37856</guid>
    </item>
    <item>
      <title>openSUSE-SU-2025:20081-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2025:20081-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-2025:20081-1</guid>
    </item>
    <item>
      <title>SUSE-SU-2025:02846-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2025:02846-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-2025:02846-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2025-37856</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-37856</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 152 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: btrfs: harden block_group::bg_list against list_del() races As far as I can tell, these calls of list_del_init() on bg_list cannot run concurrently with btrfs_mark_bg_unused() or btrfs_mark_bg_to_reclaim(), as they are in transaction error paths and situations where the block group is readonly. However, if there is any chance at all of racing with mark_bg_unused(), or a different future user of bg_list, better to be safe than sorry. Otherwise we risk the following interleaving (bg_list refcount in parens) T1 (some random op)                       T2 (btrfs_mark_bg_unused)                                         !list_empty(&amp;amp;bg-&amp;gt;bg_list); (1) list_del_init(&amp;amp;bg-&amp;gt;bg_list); (1)                                         list_move_tail (1) btrfs_put_block_group (0)                                         btrfs_delete_unused_bgs                                              bg = list_first_entry                                              list_del_init(&amp;amp;bg-&amp;gt;bg_list);                                              btrfs_put_block_group(bg); (-1) Ultimately, this results in a broken ref count that hits zero one deref early and the real final deref underflows the refcount, resulting in a WARNING.&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 152 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: btrfs: harden block_group::bg_list against list_del() races As far as I can tell, these calls of list_del_init() on bg_list cannot run concurrently with btrfs_mark_bg_unused() or btrfs_mark_bg_to_reclaim(), as they are in transaction error paths and situations where the block group is readonly. However, if there is any chance at all of racing with mark_bg_unused(), or a different future user of bg_list, better to be safe than sorry. Otherwise we risk the following interleaving (bg_list refcount in parens) T1 (some random op)                       T2 (btrfs_mark_bg_unused)                                         !list_empty(&amp;amp;bg-&amp;gt;bg_list); (1) list_del_init(&amp;amp;bg-&amp;gt;bg_list); (1)                                         list_move_tail (1) btrfs_put_block_group (0)                                         btrfs_delete_unused_bgs                                              bg = list_first_entry                                              list_del_init(&amp;amp;bg-&amp;gt;bg_list);                                              btrfs_put_block_group(bg); (-1) Ultimately, this results in a broken ref count that hits zero one deref early and the real final deref underflows the refcount, resulting in a WARNING.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-37856</guid>
    </item>
  </channel>
</rss>
