CVE-2026-74572
HighCVSS 7.5Exploitation Probability (EPSS)
Low risk28th percentile - higher than 28% of all known CVEs
Summary
In the Linux kernel, a deadlock was found in the btrfs subsystem for zoned filesystems between metadata writeback and transaction commit. The issue occurs when metadata writeback holds the zoned_meta_io_lock and then tries to activate a zone, which requires waiting for a transaction commit that needs the same lock. The fix releases the lock before calling btrfs_zone_finish_one_bg() and re-acquires it afterwards.
Risk Assessment
The deadlock can cause the btrfs filesystem on zoned devices to hang, making data inaccessible and potentially leading to service unavailability or data loss if a forced reboot is required.
Recommendation
Apply the kernel patch that fixes this issue as soon as possible and update to a kernel version containing the fix. Monitor zoned btrfs systems for signs of hangs.
Original NVD description (English source)
In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: fix deadlock between metadata writeback and transaction commit When writing out metadata extent buffers in a zoned filesystem, btree_writepages() holds fs_info->zoned_meta_io_lock across the whole writeback loop, including the call to btrfs_check_meta_write_pointer() -> check_bg_is_active(). For the tree-log block group, check_bg_is_active() may fail to activate the zone and fall back to btrfs_zone_finish_one_bg() to free an active zone. That path waits for the running transaction to commit while still holding zoned_meta_io_lock, but the committer needs that same lock to write out the tree extents, so the two tasks deadlock: Task A (kworker, metadata writeback) Task B (fsstress, transaction commit) ------------------------------------ ------------------------------------- wb_workfn() btrfs_commit_transaction(T) btree_writepages() btrfs_write_and_wait_transaction() btrfs_zoned_meta_io_lock() btrfs_write_marked_extents() btrfs_check_meta_write_pointer() btree_writepages() check_bg_is_active() [treelog_bg] btrfs_zoned_meta_io_lock() btrfs_zone_finish_one_bg() <blocks on zoned_meta_io_lock, btrfs_zone_finish() held by Task A> do_zone_finish() btrfs_inc_block_group_ro() btrfs_wait_for_commit() <blocks waiting for commit of transaction T, done by Task B> The sibling branch in check_bg_is_active() already drops zoned_meta_io_lock around do_zone_finish() for this exact reason. Do the same in the tree-log branch: release the lock around btrfs_zone_finish_one_bg() and re-acquire it afterwards. The lock only protects fs_info->active_{meta,system}_bg, which this branch does not touch, and ctx->zoned_bg keeps a reference to the block group across the unlock, so nothing is lost while the lock is dropped. This hang occasionally reproduces with fstests generic/475 on a zoned btrfs filesystem.