<?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>Tue, 06 Oct 2026 20:33:55 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-46251 — btrfs: fix block_group_tree dirty_list corruption</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-46251</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_tree dirty_list corruption&lt;/p&gt;
&lt;p&gt;When the incompat flag EXTENT_TREE_V2 is set, we unconditionally add the
block group tree to the switch_commits list before calling
switch_commit_roots, as we do for the tree root and the chunk root.
However, the block group tree uses normal root dirty tracking and in any
transaction that does an allocation and dirties a block group, the block
group root will already be linked to a list by the dirty_list field and
this use of list_add_tail() is invalid and corrupts the prev/next
members of block_group_root-&amp;gt;dirty_list.&lt;/p&gt;
&lt;p&gt;This is apparent on a subsequent list_del on the prev if we enable
CONFIG_DEBUG_LIST:&lt;/p&gt;
&lt;p&gt;[32.1571] ------------[ cut here ]------------
  [32.1572] list_del corruption. next-&amp;gt;prev should beffff958890202538, but was ffff9588992bd538. (next=ffff958890201538)
  [32.1575] WARNING: lib/list_debug.c:65 at 0x0, CPU#3: sync/607
  [32.1583] CPU: 3 UID: 0 PID: 607 Comm: sync Not tainted 6.18.0 #24PREEMPT(none)
  [32.1585] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS1.17.0-4.fc41 04/01/2014
  [32.1587] RIP: 0010:__list_del_entry_valid_or_report+0x108/0x120
  [32.1593] RSP: 0018:ffffaa288287fdd0 EFLAGS: 00010202
  [32.1594] RAX: 0000000000000001 RBX: ffff95889326e800 RCX:ffff958890201538
  [32.1596] RDX: ffff9588992bd538 RSI: ffff958890202538 RDI:ffffffff82a41e00
  [32.1597] RBP: ffff958890202538 R08: ffffffff828fc1e8 R09:00000000ffffefff…&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_tree dirty_list corruption&lt;/p&gt;
&lt;p&gt;When the incompat flag EXTENT_TREE_V2 is set, we unconditionally add the
block group tree to the switch_commits list before calling
switch_commit_roots, as we do for the tree root and the chunk root.
However, the block group tree uses normal root dirty tracking and in any
transaction that does an allocation and dirties a block group, the block
group root will already be linked to a list by the dirty_list field and
this use of list_add_tail() is invalid and corrupts the prev/next
members of block_group_root-&amp;gt;dirty_list.&lt;/p&gt;
&lt;p&gt;This is apparent on a subsequent list_del on the prev if we enable
CONFIG_DEBUG_LIST:&lt;/p&gt;
&lt;p&gt;[32.1571] ------------[ cut here ]------------
  [32.1572] list_del corruption. next-&amp;gt;prev should beffff958890202538, but was ffff9588992bd538. (next=ffff958890201538)
  [32.1575] WARNING: lib/list_debug.c:65 at 0x0, CPU#3: sync/607
  [32.1583] CPU: 3 UID: 0 PID: 607 Comm: sync Not tainted 6.18.0 #24PREEMPT(none)
  [32.1585] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS1.17.0-4.fc41 04/01/2014
  [32.1587] RIP: 0010:__list_del_entry_valid_or_report+0x108/0x120
  [32.1593] RSP: 0018:ffffaa288287fdd0 EFLAGS: 00010202
  [32.1594] RAX: 0000000000000001 RBX: ffff95889326e800 RCX:ffff958890201538
  [32.1596] RDX: ffff9588992bd538 RSI: ffff958890202538 RDI:ffffffff82a41e00
  [32.1597] RBP: ffff958890202538 R08: ffffffff828fc1e8 R09:00000000ffffefff…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-46251</guid>
    </item>
  </channel>
</rss>
