CVE-2026-53122
Received Received - Intake
Deadlock in Linux Kernel Btrfs with Flushoncommit

Publication date: 2026-06-24

Last updated on: 2026-06-24

Assigner: kernel.org

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

This vulnerability is a deadlock issue in the Linux kernel's btrfs filesystem when using the flushoncommit mount option.

The deadlock occurs between two tasks: one performing a reflink operation that copies an inline extent beyond the current size of a destination inode, and another committing a transaction that flushes delayed allocations.

Specifically, Task A clones data beyond the end of an inode, locking certain resources. Task B tries to flush data and invalidate a folio locked by Task A. Meanwhile, Task A waits for Task B's transaction to complete, causing both tasks to wait on each other indefinitely, resulting in a deadlock.

Impact Analysis

This deadlock can cause processes in the system to become blocked indefinitely, leading to system hangs or degraded performance.

Specifically, tasks related to filesystem operations on btrfs may stop progressing, potentially affecting system stability and responsiveness.

Detection Guidance

This vulnerability manifests as a deadlock in the Linux kernel's btrfs filesystem when using the flushoncommit mount option. It can be detected by observing tasks blocked for extended periods, especially related to btrfs operations.

One indication is kernel messages showing tasks blocked for more than 143 seconds, such as kworker or syz tasks stuck in D (uninterruptible sleep) state with stack traces involving btrfs functions like btrfs_invalidate_folio, extent_writepage, and transaction commits.

To detect this on your system, you can check for hung tasks and kernel logs with commands like:

  • dmesg | grep -i 'blocked for more than'
  • ps -eo state,pid,cmd | grep '^D' # Lists processes in uninterruptible sleep state
  • cat /proc/locks # To check for locks held by processes
  • journalctl -k | grep btrfs # To review kernel logs related to btrfs
Mitigation Strategies

The vulnerability is caused by a deadlock in btrfs when using the flushoncommit mount option during reflink and transaction commit operations.

Immediate mitigation steps include:

  • Avoid using the flushoncommit mount option on btrfs filesystems until the kernel is updated with the fix.
  • Update the Linux kernel to a version where this deadlock issue is resolved.
  • Monitor system logs for signs of hung tasks related to btrfs and restart affected services or the system if necessary.
Chat Assistant
Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-53122. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70
EPSS Chart