CVE-2026-53122

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix deadlock between reflink and transaction commit when using flushoncommit<br /> <br /> When using the flushoncommit mount option, we can have a deadlock between<br /> a transaction commit and a reflink operation that copied an inline extent<br /> to an offset beyond the current i_size of the destination node.<br /> <br /> The deadlock happens like this:<br /> <br /> 1) Task A clones an inline extent from inode X to an offset of inode Y<br /> that is beyond Y&amp;#39;s current i_size. This means we copied the inline<br /> extent&amp;#39;s data to a folio of inode Y that is beyond its EOF, using a<br /> call to copy_inline_to_page();<br /> <br /> 2) Task B starts a transaction commit and calls<br /> btrfs_start_delalloc_flush() to flush delalloc;<br /> <br /> 3) The delalloc flushing sees the new dirty folio of inode Y and when it<br /> attempts to flush it, it ends up at extent_writepage() and sees that<br /> the offset of the folio is beyond the i_size of inode Y, so it attempts<br /> to invalidate the folio by calling folio_invalidate(), which ends up at<br /> btrfs&amp;#39; folio invalidate callback - btrfs_invalidate_folio(). There it<br /> tries to lock the folio&amp;#39;s range in inode Y&amp;#39;s extent io tree, but it<br /> blocks since it&amp;#39;s currently locked by task A - during a reflink we lock<br /> the inodes and the source and destination ranges after flushing all<br /> delalloc and waiting for ordered extent completion - after that we<br /> don&amp;#39;t expect to have dirty folios in the ranges, the exception is if<br /> we have to copy an inline extent&amp;#39;s data (because the destination offset<br /> is not zero);<br /> <br /> 4) Task A then attempts to start a transaction to update the inode item,<br /> and then it&amp;#39;s blocked since the current transaction is in the<br /> TRANS_STATE_COMMIT_START state. Therefore task A has to wait for the<br /> current transaction to become unblocked (its state &gt;=<br /> TRANS_STATE_UNBLOCKED).<br /> <br /> So task A is waiting for the transaction commit done by task B, and<br /> the later waiting on the extent lock of inode Y that is currently<br /> held by task A.<br /> <br /> Syzbot recently reported this with the following stack traces:<br /> <br /> INFO: task kworker/u8:7:1053 blocked for more than 143 seconds.<br /> Not tainted syzkaller #0<br /> "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> task:kworker/u8:7 state:D stack:23520 pid:1053 tgid:1053 ppid:2 task_flags:0x4208060 flags:0x00080000<br /> Workqueue: writeback wb_workfn (flush-btrfs-46)<br /> Call Trace:<br /> <br /> context_switch kernel/sched/core.c:5298 [inline]<br /> __schedule+0x1553/0x5240 kernel/sched/core.c:6911<br /> __schedule_loop kernel/sched/core.c:6993 [inline]<br /> schedule+0x164/0x360 kernel/sched/core.c:7008<br /> wait_extent_bit fs/btrfs/extent-io-tree.c:811 [inline]<br /> btrfs_lock_extent_bits+0x59c/0x700 fs/btrfs/extent-io-tree.c:1914<br /> btrfs_lock_extent fs/btrfs/extent-io-tree.h:152 [inline]<br /> btrfs_invalidate_folio+0x43d/0xc40 fs/btrfs/inode.c:7704<br /> extent_writepage fs/btrfs/extent_io.c:1852 [inline]<br /> extent_write_cache_pages fs/btrfs/extent_io.c:2580 [inline]<br /> btrfs_writepages+0x12ff/0x2440 fs/btrfs/extent_io.c:2713<br /> do_writepages+0x32e/0x550 mm/page-writeback.c:2554<br /> __writeback_single_inode+0x133/0x11a0 fs/fs-writeback.c:1750<br /> writeback_sb_inodes+0x995/0x19d0 fs/fs-writeback.c:2042<br /> wb_writeback+0x456/0xb70 fs/fs-writeback.c:2227<br /> wb_do_writeback fs/fs-writeback.c:2374 [inline]<br /> wb_workfn+0x41a/0xf60 fs/fs-writeback.c:2414<br /> process_one_work kernel/workqueue.c:3276 [inline]<br /> process_scheduled_works+0xb6e/0x18c0 kernel/workqueue.c:3359<br /> worker_thread+0xa53/0xfc0 kernel/workqueue.c:3440<br /> kthread+0x388/0x470 kernel/kthread.c:436<br /> ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245<br /> <br /> INFO: task syz.4.64:6910 blocked for more than 143 seconds.<br /> Not tainted syzkaller #0<br /> "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> task:syz.4.64 state:D stack:22752 pid:6910 tgid:<br /> ---truncated---