DEBIAN-CVE-2026-23018

In the Linux kernel, the following vulnerability has been resolved: btrfs: release path before initializing extent tree in btrfsreadlockedinode() In btrfsreadlockedinode() we are calling btrfsinitfileextenttree() while holding a path with a read locked leaf from a subvolume tree, and btrfsinitfileextenttree() may do a GFPKERNEL allocation, which can trigger reclaim. This can create a circular lock dependency which lockdep warns about with the following splat: [6.1433] ====================================================== [6.1574] WARNING: possible circular locking dependency detected [6.1583] 6.18.0+ #4 Tainted: G U [6.1591] ------------------------------------------------------ [6.1599] kswapd0/117 is trying to acquire lock: [6.1606] ffff8d9b6333c5b8 (&delayednode->mutex){+.+.}-{3:3}, at: __btrfsreleasedelayednode.part.0+0x39/0x2f0 [6.1625] but task is already holding lock: [6.1633] ffffffffa4ab8ce0 (fsreclaim){+.+.}-{0:0}, at: balancepgdat+0x195/0xc60 [6.1646] which lock already depends on the new lock. [6.1657] the existing dependency chain (in reverse order) is: [6.1667] -> #2 (fsreclaim){+.+.}-{0:0}: [6.1677] fsreclaimacquire+0x9d/0xd0 [6.1685] __kmalloccachenoprof+0x59/0x750 [6.1694] btrfsinitfileextenttree+0x90/0x100 [6.1702] btrfsreadlockedinode+0xc3/0x6b0 [6.1710] btrfsiget+0xbb/0xf0 [6.1716] btrfslookupdentry+0x3c5/0x8e0 [6.1724] btrfslookup+0x12/0x30 [6.1731] lookupopen.isra.0+0x1aa/0x6a0 [6.1739] pathopenat+0x5f7/0xc60 [6.1746] dofilpopen+0xd6/0x180 [6.1753] dosys_openat2+0x8b/0xe0 [6.1760] __x64sysopenat+0x54/0xa0 [6.1768] dosyscall64+0x97/0x3e0 [6.1776] entrySYSCALL64afterhwframe+0x76/0x7e [6.1784] -> #1 (btrfs-tree-00){++++}-{3:3}: [6.1794] lockrelease+0x127/0x2a0 [6.1801] upread+0x1b/0x30 [6.1808] btrfssearchslot+0x8e0/0xff0 [6.1817] btrfslookupinode+0x52/0xd0 [6.1825] __btrfsupdatedelayedinode+0x73/0x520 [6.1833] btrfscommitinodedelayedinode+0x11a/0x120 [6.1842] btrfsloginode+0x608/0x1aa0 [6.1849] btrfsloginodeparent+0x249/0xf80 [6.1857] btrfslogdentrysafe+0x3e/0x60 [6.1865] btrfssyncfile+0x431/0x690 [6.1872] dofsync+0x39/0x80 [6.1879] __x64sysfsync+0x13/0x20 [6.1887] dosyscall64+0x97/0x3e0 [6.1894] entrySYSCALL64afterhwframe+0x76/0x7e [6.1903] -> #0 (&delayed_node->mutex){+.+.}-{3:3}: [6.1913] __lockacquire+0x15e9/0x2820 [6.1920] lockacquire+0xc9/0x2d0 [6.1927] __mutex_lock+0xcc/0x10a0 [6.1934] __btrfsreleasedelayednode.part.0+0x39/0x2f0 [6.1944] btrfsevictinode+0x20b/0x4b0 [6.1952] evict+0x15a/0x2f0 [6.1958] pruneicachesb+0x91/0xd0 [6.1966] supercachescan+0x150/0x1d0 [6.1974] doshrinkslab+0x155/0x6f0 [6.1981] shrinkslab+0x48e/0x890 [6.1988] shrinkone+0x11a/0x1f0 [6.1995] shrinknode+0xbfd/0x1320 [6.1002] balancepgdat+0x67f/0xc60 [6.1321] kswapd+0x1dc/0x3e0 [6.1643] kthread+0xff/0x240 [6.1965] retfromfork+0x223/0x280 [6.1287] retfromforkasm+0x1a/0x30 [6.1616] other info that might help us debug this: [6.1561] Chain exists of: &delayednode->mutex --> btrfs-tree-00 --> fsreclaim [6.1503] Possible unsafe locking scenario: [6.1110] CPU0 CPU1 [6.1411] ---- ---- [6.1707] lock(fsreclaim); [6.1998] lock(btrfs-tree-00); [6.1291] lock(fsreclaim); [6.1581] lock(&del ---truncated---