<?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://vulnerability.circl.lu</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>Mon, 05 Oct 2026 16:39:34 +0000</lastBuildDate>
    <item>
      <title>CVE-2025-37856 — btrfs: harden block_group::bg_list against list_del() races</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2025-37856</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;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;&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;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://vulnerability.circl.lu/vuln/cve-2025-37856</guid>
    </item>
  </channel>
</rss>
