Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-53122

CVE-2026-53122: Linux Kernel Btrfs DOS Vulnerability

CVE-2026-53122 is a denial of service vulnerability in the Linux kernel btrfs filesystem causing deadlock between reflink and transaction commit. This article covers the technical details, affected versions, and mitigation.

Published:

CVE-2026-53122 Overview

CVE-2026-53122 is a deadlock vulnerability in the Linux kernel's Btrfs filesystem implementation. The flaw occurs between a reflink operation and a transaction commit when the flushoncommit mount option is enabled. A reflink that copies an inline extent to an offset beyond the destination inode's i_size can leave a dirty folio past EOF. When a concurrent transaction commit attempts to flush delalloc, the writeback path calls btrfs_invalidate_folio() and blocks on an extent lock already held by the reflink task, while the reflink task waits for the in-progress transaction commit to unblock.

Critical Impact

Concurrent Btrfs reflink and transaction commit operations on a filesystem mounted with flushoncommit can deadlock kernel writeback workers and user tasks, producing hung-task warnings and filesystem stalls.

Affected Products

  • Linux kernel Btrfs filesystem with flushoncommit mount option enabled
  • Stable kernel branches receiving the fixes referenced in commits 6f0f9c0, 73be4a0, 9a24f00, and b48c980
  • Systems using reflink (FICLONE/FICLONERANGE) operations on Btrfs volumes

Discovery Timeline

  • 2026-06-24 - CVE-2026-53122 published to NVD
  • 2026-06-24 - Last updated in NVD database

Technical Details for CVE-2026-53122

Vulnerability Analysis

The deadlock involves two cooperating tasks operating on a Btrfs filesystem mounted with flushoncommit. Task A performs a reflink that clones an inline extent from a source inode to an offset beyond the destination inode's i_size. The clone path uses copy_inline_to_page(), which dirties a folio past end-of-file on the destination inode. Task A holds the extent io tree lock on the destination range during this operation.

Task B begins a transaction commit and calls btrfs_start_delalloc_flush() to flush dirty data. The writeback worker walks the destination inode, enters extent_writepage(), and detects that the dirty folio sits beyond i_size. It then calls folio_invalidate(), which dispatches to btrfs_invalidate_folio() at fs/btrfs/inode.c:7704. That function calls btrfs_lock_extent_bits() and blocks because Task A already holds the lock on that range.

Task A subsequently attempts to start a transaction to update the inode item, but the current transaction is in TRANS_STATE_COMMIT_START. Task A must wait until the transaction reaches TRANS_STATE_UNBLOCKED, which cannot happen because Task B's commit is stuck behind Task A's extent lock. The two tasks form a circular wait.

Root Cause

The root cause is a lock-ordering inversion between the Btrfs extent io tree lock and the transaction state machine. The reflink fast path for inline extents leaves dirty folios past EOF while still holding the extent range lock. The writeback path triggered by flushoncommit does not expect dirty folios beyond i_size during transaction commit and attempts to acquire the same range lock to invalidate them.

Attack Vector

This is a local concurrency issue, not a remote attack vector. A local user with permission to perform reflink operations on a Btrfs filesystem mounted with flushoncommit can trigger the deadlock by repeatedly cloning inline extents to offsets beyond the destination file's i_size while transaction commits occur. The Syzbot reproducer demonstrates the hang through standard clone system calls. Successful triggering halts the writeback workqueue and any task waiting on the affected transaction, producing hung_task warnings after 143 seconds.

The vulnerability mechanism is described in prose only because no verified exploit code is published. Technical details are available in the referenced upstream kernel commits.

Detection Methods for CVE-2026-53122

Indicators of Compromise

  • Kernel hung_task messages naming wb_workfn (flush-btrfs) and processes blocked in btrfs_invalidate_folio or wait_extent_bit.
  • Tasks stuck in state D with stack traces through btrfs_writepages, extent_writepage, and btrfs_lock_extent_bits.
  • User processes calling clone/ioctl(FICLONERANGE) blocked while waiting for transaction state to reach TRANS_STATE_UNBLOCKED.

Detection Strategies

  • Monitor dmesg and /var/log/kern.log for INFO: task ... blocked for more than 143 seconds entries referencing Btrfs writeback workers.
  • Inspect /proc/<pid>/stack on stalled processes for the call chain btrfs_invalidate_foliobtrfs_lock_extent_bitswait_extent_bit.
  • Audit Btrfs mount options across hosts and flag filesystems mounted with flushoncommit running unpatched kernels.

Monitoring Recommendations

  • Alert on sustained growth of D-state processes or stalled kworker/u* writeback threads on Btrfs hosts.
  • Track filesystem-level latency metrics for write and sync operations to catch transaction commit stalls early.
  • Centralize kernel logs and create rules that match the wait_extent_bit and btrfs_invalidate_folio symbols in hung-task traces.

How to Mitigate CVE-2026-53122

Immediate Actions Required

  • Update to a Linux kernel build that incorporates the upstream Btrfs fix referenced by commits 6f0f9c0, 73be4a0, 9a24f00, or b48c980.
  • Inventory all Btrfs filesystems on managed hosts and confirm whether flushoncommit is set in /etc/fstab or systemd mount units.
  • On unpatched systems, restrict use of reflink operations on Btrfs volumes mounted with flushoncommit until patches are deployed.

Patch Information

The fix is distributed across the upstream stable trees in the following commits: Kernel Git Commit 6f0f9c0, Kernel Git Commit 73be4a0, Kernel Git Commit 9a24f00, and Kernel Git Commit b48c980. Distributions backport these commits into their stable kernel packages. Apply vendor kernel updates through standard package management and reboot to activate the patched kernel.

Workarounds

  • Remount affected Btrfs filesystems without the flushoncommit option until patched kernels are deployed.
  • Avoid reflink workloads that clone inline extents to offsets beyond the destination file's current size on vulnerable kernels.
  • Where possible, schedule transaction-heavy workloads and reflink-heavy workloads on separate filesystems to reduce contention.
bash
# Remove flushoncommit from an active Btrfs mount
mount -o remount,noflushoncommit /mnt/btrfs-volume

# Verify active mount options
cat /proc/self/mountinfo | grep btrfs

# Confirm running kernel version after patching
uname -r

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.