CVE-2026-53122

What it actually does

This flaw is a Linux kernel Btrfs filesystem deadlock involving reflink operations and transaction commits when the filesystem is mounted with the flushoncommit option. A reflink that copies an inline extent beyond the destination file's current end-of-file can leave a dirty folio in a range locked by the reflink path. During transaction commit, Btrfs delalloc flushing may try to invalidate that same folio and block on the locked extent range, while the reflink operation waits for the transaction commit to unblock. The result is an unresolvable wait cycle in kernel filesystem code, causing tasks to hang in uninterruptible sleep and potentially degrading or halting filesystem I/O on the affected Btrfs mount.

Why it matters to the business

Successful exploitation can cause systems using affected Btrfs configurations to experience hung I/O, stalled workloads, degraded service availability, and potential need for administrative recovery such as remounting or rebooting. The impact is most relevant to Linux systems that use Btrfs with reflink-capable workloads and the flushoncommit mount option. EPSS is currently very low and there is no known CISA KEV listing or ransomware association, but availability-sensitive systems should still prioritize kernel updates because filesystem deadlocks can disrupt production workloads and may be difficult to recover from without downtime.

How an attack unfolds

An attacker needs the ability to perform filesystem operations on an affected Btrfs filesystem mounted with flushoncommit. They create or control files such that an inline extent from one inode is cloned via reflink into another file at an offset beyond the destination file's current size. This causes Btrfs to copy inline data into a page or folio beyond EOF while the reflink path holds extent-range locks. If a transaction commit occurs concurrently, the commit path flushes delayed allocation, encounters the dirty folio beyond EOF, and attempts to invalidate it. The invalidation path blocks waiting for the extent range lock held by the reflink operation. The reflink operation then attempts to start or continue a transaction and blocks behind the transaction commit. Both paths wait on each other, leaving kernel tasks stuck and filesystem writeback or transaction progress impaired.

How to fix it

Apply a Linux kernel update that includes the Btrfs fix for this issue from the relevant distribution or kernel vendor. No specific fixed package versions were provided in the input, so use vendor advisories for the exact corrected kernel build for each distribution and kernel stream. Where immediate patching is not possible, reduce exposure by avoiding the flushoncommit mount option on Btrfs filesystems where operationally acceptable, restricting untrusted local users or workloads from performing reflink-heavy file operations, and isolating workloads that can create or clone files on Btrfs volumes. Reboot into the patched kernel after installation, because kernel filesystem fixes are not effective until the running kernel is replaced.

How to confirm the fix worked

Confirm the running kernel version is at or above the vendor-fixed build, not merely that an updated package is installed. Review Btrfs mount options and verify whether affected filesystems are mounted with flushoncommit. Validate that production Btrfs mounts can complete reflink-capable file operations and transaction-heavy write workloads without hung tasks. Where feasible, test on a non-production system using the same kernel stream, Btrfs configuration, and mount options. Check kernel logs after validation for absence of hung task reports involving Btrfs writeback, extent locking, folio invalidation, or transaction commit paths.

Typical attack path

1. Gain local ability to create, modify, and reflink files on a Btrfs filesystem mounted with the flushoncommit option.
2. Prepare a source file with an inline extent and a destination file whose current size is smaller than the target clone offset.
3. Trigger a reflink or clone operation that copies the inline extent into the destination file beyond its current EOF.
4. Induce or wait for a Btrfs transaction commit and delayed allocation flush to occur concurrently.
5. Cause the transaction commit path and reflink path to enter a circular wait on extent locks and transaction state.
6. Observe resulting hung tasks, stalled Btrfs writeback, degraded filesystem availability, or system-level service disruption.

How to detect it

Look for signs of prior or ongoing exploitation in kernel logs, system journals, hypervisor or console logs, and monitoring alerts that capture hung tasks, blocked writeback workers, Btrfs transaction stalls, or long I/O waits. Relevant artifacts include tasks stuck in uninterruptible sleep, messages such as blocked for more than the hung task timeout, Btrfs writeback workers named flush-btrfs, and stack traces involving btrfs_invalidate_folio, btrfs_writepages, wait_extent_bit, btrfs_lock_extent_bits, extent_writepage, or transaction commit paths. Correlate these events with Btrfs filesystems mounted with flushoncommit and with local user, container, build, backup, deduplication, or file-cloning activity around the same time. Because this is a denial-of-service deadlock rather than a code-execution vulnerability, durable file-based IOCs are unlikely; detection should focus on kernel telemetry, mount configuration, and workload activity preceding the hang.

• flushoncommit
• INFO: task
• blocked for more than
• hung_task_timeout_secs
• flush-btrfs-
• btrfs_invalidate_folio
• btrfs_writepages
• extent_writepage
• extent_write_cache_pages
• wait_extent_bit
• btrfs_lock_extent_bits
• btrfs_lock_extent
• btrfs_start_delalloc_flush
• TRANS_STATE_COMMIT_START
• TRANS_STATE_UNBLOCKED
• Workqueue: writeback wb_workfn
• state:D
• copy_inline_to_page

What your security team should do

• Inventory Linux systems using Btrfs and identify mounts using the flushoncommit option.
• Prioritize kernel updates for systems where Btrfs supports multi-user, container, build, backup, virtualization, or other reflink-capable workloads.
• If patching is delayed, remove the flushoncommit mount option where business requirements allow and remount or reboot to apply the change.
• Restrict local or workload-level access that permits untrusted users to create files, perform reflinks, or run high-volume filesystem operations on affected Btrfs mounts.
• Monitor kernel logs for hung task reports and Btrfs stack traces until all affected systems are patched.
• Ensure operational runbooks include recovery steps for Btrfs filesystem hangs, including safe service drain, remount, or reboot procedures.