<?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, 28 Sep 2026 17:35:26 +0000</lastBuildDate>
    <item>
      <title>CVE-2025-22115 — btrfs: fix block group refcount race in btrfs_create_pending_block_groups()</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2025-22115</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: fix block group refcount race in btrfs_create_pending_block_groups()&lt;/p&gt;
&lt;p&gt;Block group creation is done in two phases, which results in a slightly
unintuitive property: a block group can be allocated/deallocated from
after btrfs_make_block_group() adds it to the space_info with
btrfs_add_bg_to_space_info(), but before creation is completely completed
in btrfs_create_pending_block_groups(). As a result, it is possible for a
block group to go unused and have &amp;#39;btrfs_mark_bg_unused&amp;#39; called on it
concurrently with &amp;#39;btrfs_create_pending_block_groups&amp;#39;. This causes a
number of issues, which were fixed with the block group flag
&amp;#39;BLOCK_GROUP_FLAG_NEW&amp;#39;.&lt;/p&gt;
&lt;p&gt;However, this fix is not quite complete. Since it does not use the
unused_bg_lock, it is possible for the following race to occur:&lt;/p&gt;
&lt;p&gt;btrfs_create_pending_block_groups            btrfs_mark_bg_unused
                                           if list_empty // false
        list_del_init
        clear_bit
                                           else if (test_bit) // true
                                                list_move_tail&lt;/p&gt;
&lt;p&gt;And we get into the exact same broken ref count and invalid new_bgs
state for transaction cleanup that BLOCK_GROUP_FLAG_NEW was designed to
prevent.&lt;/p&gt;
&lt;p&gt;The broken refcount aspect will result in a warning like:&lt;/p&gt;
&lt;p&gt;[1272.943527] refcount_t: underflow; use-after-free.
  [1272.943967] WARNING: CPU: 1 PID: 61 at lib/refcount.c:28 refcount_warn…&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: fix block group refcount race in btrfs_create_pending_block_groups()&lt;/p&gt;
&lt;p&gt;Block group creation is done in two phases, which results in a slightly
unintuitive property: a block group can be allocated/deallocated from
after btrfs_make_block_group() adds it to the space_info with
btrfs_add_bg_to_space_info(), but before creation is completely completed
in btrfs_create_pending_block_groups(). As a result, it is possible for a
block group to go unused and have &amp;#39;btrfs_mark_bg_unused&amp;#39; called on it
concurrently with &amp;#39;btrfs_create_pending_block_groups&amp;#39;. This causes a
number of issues, which were fixed with the block group flag
&amp;#39;BLOCK_GROUP_FLAG_NEW&amp;#39;.&lt;/p&gt;
&lt;p&gt;However, this fix is not quite complete. Since it does not use the
unused_bg_lock, it is possible for the following race to occur:&lt;/p&gt;
&lt;p&gt;btrfs_create_pending_block_groups            btrfs_mark_bg_unused
                                           if list_empty // false
        list_del_init
        clear_bit
                                           else if (test_bit) // true
                                                list_move_tail&lt;/p&gt;
&lt;p&gt;And we get into the exact same broken ref count and invalid new_bgs
state for transaction cleanup that BLOCK_GROUP_FLAG_NEW was designed to
prevent.&lt;/p&gt;
&lt;p&gt;The broken refcount aspect will result in a warning like:&lt;/p&gt;
&lt;p&gt;[1272.943527] refcount_t: underflow; use-after-free.
  [1272.943967] WARNING: CPU: 1 PID: 61 at lib/refcount.c:28 refcount_warn…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2025-22115</guid>
    </item>
  </channel>
</rss>
