CVE-2023-54224

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, btrfsinsertdelayed_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 _btrfsrundelayeditems(), 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: _btrfsreleasedelayednode+0x9a/0xaa0 fs/btrfs/delayed-inode.c:256

but task is already holding lock: ffff88802a5ab8e8 (btrfs-tree-00){++++}-{3:3}, at: __btrfstreelock+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}: __lockrelease kernel/locking/lockdep.c:5475 [inline] lockrelease+0x36f/0x9d0 kernel/locking/lockdep.c:5781 up_write+0x79/0x580 kernel/locking/rwsem.c:1625 btrfstreeunlockrw fs/btrfs/locking.h:189 [inline] btrfsunlockupsafe+0x179/0x3b0 fs/btrfs/locking.c:239 searchleaf fs/btrfs/ctree.c:1986 [inline] btrfssearchslot+0x2511/0x2f80 fs/btrfs/ctree.c:2230 btrfsinsertemptyitems+0x9c/0x180 fs/btrfs/ctree.c:4376 btrfsinsertdelayeditem fs/btrfs/delayed-inode.c:746 [inline] btrfsinsertdelayeditems fs/btrfs/delayed-inode.c:824 [inline] __btrfscommitinodedelayeditems+0xd24/0x2410 fs/btrfs/delayed-inode.c:1111 _btrfsrundelayeditems+0x1db/0x430 fs/btrfs/delayed-inode.c:1153 flushspace+0x269/0xe70 fs/btrfs/space-info.c:723 btrfsasyncreclaimmetadataspace+0x106/0x350 fs/btrfs/space-info.c:1078 processonework+0x92c/0x12c0 kernel/workqueue.c:2600 workerthread+0xa63/0x1210 kernel/workqueue.c:2751 kthread+0x2b8/0x350 kernel/kthread.c:389 retfromfork+0x2e/0x60 arch/x86/kernel/process.c:145 retfromforkasm+0x11/0x20 arch/x86/entry/entry64.S:304

-> #0 (&delayednode->mutex){+.+.}-{3:3}: checkprevadd kernel/locking/lockdep.c:3142 [inline] checkprevsadd kernel/locking/lockdep.c:3261 [inline] validatechain kernel/locking/lockdep.c:3876 [inline] __lockacquire+0x39ff/0x7f70 kernel/locking/lockdep.c:5144 lockacquire+0x1e3/0x520 kernel/locking/lockdep.c:5761 __mutexlockcommon+0x1d8/0x2530 kernel/locking/mutex.c:603 __mutexlock kernel/locking/mutex.c:747 [inline] mutexlock_nested+0x1b/0x20 kernel/locking/mutex.c:799 __btrfsreleasedelayednode+0x9a/0xaa0 fs/btrfs/delayed-inode.c:256 btrfsreleasedelayednode fs/btrfs/delayed-inode.c:281 [inline] __btrfsrundelayeditems+0x2b5/0x430 fs/btrfs/delayed-inode.c:1156 btrfscommittransaction+0x859/0x2ff0 fs/btrfs/transaction.c:2276 btrfssyncfile+0xf56/0x1330 fs/btrfs/file.c:1988 vfsfsyncrange fs/sync.c:188 [inline] vfsfsync fs/sync.c:202 [inline] do_fsync fs/sync.c:212 [inline] __dosysfsync fs/sync.c:220 [inline] __sesysfsync fs/sync.c:218 [inline] __x64sysfsync+0x196/0x1e0 fs/sync.c:218 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x41/0xc0 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd

other info that ---truncated---