VYPR
Unrated severityNVD Advisory· Published Dec 30, 2025· Updated Apr 15, 2026

CVE-2023-54224

CVE-2023-54224

Description

In the Linux kernel, the following vulnerability has been resolved:

btrfs: fix lockdep splat and potential deadlock after failure running delayed items

When running delayed items we are holding a delayed node's mutex and then we will attempt to modify a subvolume btree to insert/update/delete the delayed items. However if have an error during the insertions for example, btrfs_insert_delayed_items() may return with a path that has locked extent buffers (a leaf at the very least), and then we attempt to release the delayed node at __btrfs_run_delayed_items(), which requires taking the delayed node's mutex, causing an ABBA type of deadlock. This was reported by syzbot and the lockdep splat is the following:

WARNING: possible circular locking dependency detected 6.5.0-rc7-syzkaller-00024-g93f5de5f648d #0 Not tainted ------------------------------------------------------ syz-executor.2/13257 is trying to acquire lock: ffff88801835c0c0 (&delayed_node->mutex){+.+.}-{3:3}, at: __btrfs_release_delayed_node+0x9a/0xaa0 fs/btrfs/delayed-inode.c:256

but task is already holding lock: ffff88802a5ab8e8 (btrfs-tree-00){++++}-{3:3}, at: __btrfs_tree_lock+0x3c/0x2a0 fs/btrfs/locking.c:198

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (btrfs-tree-00){++++}-{3:3}: __lock_release kernel/locking/lockdep.c:5475 [inline] lock_release+0x36f/0x9d0 kernel/locking/lockdep.c:5781 up_write+0x79/0x580 kernel/locking/rwsem.c:1625 btrfs_tree_unlock_rw fs/btrfs/locking.h:189 [inline] btrfs_unlock_up_safe+0x179/0x3b0 fs/btrfs/locking.c:239 search_leaf fs/btrfs/ctree.c:1986 [inline] btrfs_search_slot+0x2511/0x2f80 fs/btrfs/ctree.c:2230 btrfs_insert_empty_items+0x9c/0x180 fs/btrfs/ctree.c:4376 btrfs_insert_delayed_item fs/btrfs/delayed-inode.c:746 [inline] btrfs_insert_delayed_items fs/btrfs/delayed-inode.c:824 [inline] __btrfs_commit_inode_delayed_items+0xd24/0x2410 fs/btrfs/delayed-inode.c:1111 __btrfs_run_delayed_items+0x1db/0x430 fs/btrfs/delayed-inode.c:1153 flush_space+0x269/0xe70 fs/btrfs/space-info.c:723 btrfs_async_reclaim_metadata_space+0x106/0x350 fs/btrfs/space-info.c:1078 process_one_work+0x92c/0x12c0 kernel/workqueue.c:2600 worker_thread+0xa63/0x1210 kernel/workqueue.c:2751 kthread+0x2b8/0x350 kernel/kthread.c:389 ret_from_fork+0x2e/0x60 arch/x86/kernel/process.c:145 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304

-> #0 (&delayed_node->mutex){+.+.}-{3:3}: check_prev_add kernel/locking/lockdep.c:3142 [inline] check_prevs_add kernel/locking/lockdep.c:3261 [inline] validate_chain kernel/locking/lockdep.c:3876 [inline] __lock_acquire+0x39ff/0x7f70 kernel/locking/lockdep.c:5144 lock_acquire+0x1e3/0x520 kernel/locking/lockdep.c:5761 __mutex_lock_common+0x1d8/0x2530 kernel/locking/mutex.c:603 __mutex_lock kernel/locking/mutex.c:747 [inline] mutex_lock_nested+0x1b/0x20 kernel/locking/mutex.c:799 __btrfs_release_delayed_node+0x9a/0xaa0 fs/btrfs/delayed-inode.c:256 btrfs_release_delayed_node fs/btrfs/delayed-inode.c:281 [inline] __btrfs_run_delayed_items+0x2b5/0x430 fs/btrfs/delayed-inode.c:1156 btrfs_commit_transaction+0x859/0x2ff0 fs/btrfs/transaction.c:2276 btrfs_sync_file+0xf56/0x1330 fs/btrfs/file.c:1988 vfs_fsync_range fs/sync.c:188 [inline] vfs_fsync fs/sync.c:202 [inline] do_fsync fs/sync.c:212 [inline] __do_sys_fsync fs/sync.c:220 [inline] __se_sys_fsync fs/sync.c:218 [inline] __x64_sys_fsync+0x196/0x1e0 fs/sync.c:218 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd

other info that ---truncated---

AI Insight

LLM-synthesized narrative grounded in this CVE's description and references.

A lock ordering issue in the Linux kernel's Btrfs delayed items code can lead to a deadlock when an error occurs during insertion, as the delayed node mutex is reacquired while holding a tree lock.

Root

Cause

The vulnerability is a lock ordering problem in the Btrfs filesystem's delayed items handling. When running delayed items, the code holds a delayed node's mutex and then modifies the subvolume btree to insert, update, or delete items. If an error occurs during these insertions, btrfs_insert_delayed_items() may return with a path that still holds locked extent buffers (typically a leaf). The subsequent cleanup path in __btrfs_run_delayed_items() then attempts to release the delayed node by calling __btrfs_release_delayed_node(), which tries to acquire the same delayed node's mutex. This creates an ABBA deadlock: the mutex is already held, while the caller holds a tree lock (btrfs-tree-00). Lockdep reports this as a possible circular locking dependency [1].

Exploitation

Scenario

To trigger this deadlock, an attacker or local user must be able to perform operations that cause delayed item insertion in Btrfs and then trigger an error during that insertion. The attack surface is accessible to any user with write access to a Btrfs filesystem. The deadlock manifests as a system hang or unresponsive filesystem, as the kernel thread processing delayed items becomes permanently blocked. No authentication beyond filesystem write permissions is required.

Impact

A successful exploitation results in a denial of service (DoS) on the affected system. The deadlock prevents completion of critical filesystem metadata updates, potentially causing the filesystem to become read-only or forcing a system reboot. The CVSS score of 5.5 reflects a medium severity, as it primarily affects availability with low attack complexity and local access [1].

Mitigation

The fix is included in the Linux kernel commit 32247b9526bf. This commit resolves the lock ordering by ensuring that the delayed node mutex is released before calling code that might lock tree buffers, or by restructuring the error path to avoid reacquiring the mutex. Users should update to a kernel version containing this commit or its backports. No workaround is provided; the vulnerability is patched in the mainline kernel [1].

AI Insight generated on May 19, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.

Affected products

2

Patches

4

Vulnerability mechanics

Generated by null/stub on May 9, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.

References

4

News mentions

0

No linked articles in our index yet.