CVE-2026-23018

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: release path before initializing extent tree in btrfs_read_locked_inode()<br /> <br /> In btrfs_read_locked_inode() we are calling btrfs_init_file_extent_tree()<br /> while holding a path with a read locked leaf from a subvolume tree, and<br /> btrfs_init_file_extent_tree() may do a GFP_KERNEL allocation, which can<br /> trigger reclaim.<br /> <br /> This can create a circular lock dependency which lockdep warns about with<br /> the following splat:<br /> <br /> [6.1433] ======================================================<br /> [6.1574] WARNING: possible circular locking dependency detected<br /> [6.1583] 6.18.0+ #4 Tainted: G U<br /> [6.1591] ------------------------------------------------------<br /> [6.1599] kswapd0/117 is trying to acquire lock:<br /> [6.1606] ffff8d9b6333c5b8 (&amp;delayed_node-&gt;mutex){+.+.}-{3:3}, at: __btrfs_release_delayed_node.part.0+0x39/0x2f0<br /> [6.1625]<br /> but task is already holding lock:<br /> [6.1633] ffffffffa4ab8ce0 (fs_reclaim){+.+.}-{0:0}, at: balance_pgdat+0x195/0xc60<br /> [6.1646]<br /> which lock already depends on the new lock.<br /> <br /> [6.1657]<br /> the existing dependency chain (in reverse order) is:<br /> [6.1667]<br /> -&gt; #2 (fs_reclaim){+.+.}-{0:0}:<br /> [6.1677] fs_reclaim_acquire+0x9d/0xd0<br /> [6.1685] __kmalloc_cache_noprof+0x59/0x750<br /> [6.1694] btrfs_init_file_extent_tree+0x90/0x100<br /> [6.1702] btrfs_read_locked_inode+0xc3/0x6b0<br /> [6.1710] btrfs_iget+0xbb/0xf0<br /> [6.1716] btrfs_lookup_dentry+0x3c5/0x8e0<br /> [6.1724] btrfs_lookup+0x12/0x30<br /> [6.1731] lookup_open.isra.0+0x1aa/0x6a0<br /> [6.1739] path_openat+0x5f7/0xc60<br /> [6.1746] do_filp_open+0xd6/0x180<br /> [6.1753] do_sys_openat2+0x8b/0xe0<br /> [6.1760] __x64_sys_openat+0x54/0xa0<br /> [6.1768] do_syscall_64+0x97/0x3e0<br /> [6.1776] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [6.1784]<br /> -&gt; #1 (btrfs-tree-00){++++}-{3:3}:<br /> [6.1794] lock_release+0x127/0x2a0<br /> [6.1801] up_read+0x1b/0x30<br /> [6.1808] btrfs_search_slot+0x8e0/0xff0<br /> [6.1817] btrfs_lookup_inode+0x52/0xd0<br /> [6.1825] __btrfs_update_delayed_inode+0x73/0x520<br /> [6.1833] btrfs_commit_inode_delayed_inode+0x11a/0x120<br /> [6.1842] btrfs_log_inode+0x608/0x1aa0<br /> [6.1849] btrfs_log_inode_parent+0x249/0xf80<br /> [6.1857] btrfs_log_dentry_safe+0x3e/0x60<br /> [6.1865] btrfs_sync_file+0x431/0x690<br /> [6.1872] do_fsync+0x39/0x80<br /> [6.1879] __x64_sys_fsync+0x13/0x20<br /> [6.1887] do_syscall_64+0x97/0x3e0<br /> [6.1894] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [6.1903]<br /> -&gt; #0 (&amp;delayed_node-&gt;mutex){+.+.}-{3:3}:<br /> [6.1913] __lock_acquire+0x15e9/0x2820<br /> [6.1920] lock_acquire+0xc9/0x2d0<br /> [6.1927] __mutex_lock+0xcc/0x10a0<br /> [6.1934] __btrfs_release_delayed_node.part.0+0x39/0x2f0<br /> [6.1944] btrfs_evict_inode+0x20b/0x4b0<br /> [6.1952] evict+0x15a/0x2f0<br /> [6.1958] prune_icache_sb+0x91/0xd0<br /> [6.1966] super_cache_scan+0x150/0x1d0<br /> [6.1974] do_shrink_slab+0x155/0x6f0<br /> [6.1981] shrink_slab+0x48e/0x890<br /> [6.1988] shrink_one+0x11a/0x1f0<br /> [6.1995] shrink_node+0xbfd/0x1320<br /> [6.1002] balance_pgdat+0x67f/0xc60<br /> [6.1321] kswapd+0x1dc/0x3e0<br /> [6.1643] kthread+0xff/0x240<br /> [6.1965] ret_from_fork+0x223/0x280<br /> [6.1287] ret_from_fork_asm+0x1a/0x30<br /> [6.1616]<br /> other info that might help us debug this:<br /> <br /> [6.1561] Chain exists of:<br /> &amp;delayed_node-&gt;mutex --&gt; btrfs-tree-00 --&gt; fs_reclaim<br /> <br /> [6.1503] Possible unsafe locking scenario:<br /> <br /> [6.1110] CPU0 CPU1<br /> [6.1411] ---- ----<br /> [6.1707] lock(fs_reclaim);<br /> [6.1998] lock(btrfs-tree-00);<br /> [6.1291] lock(fs_reclaim);<br /> [6.1581] lock(&amp;del<br /> ---truncated---