CVE-2023-54023
Description
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix race between balance and cancel/pause
Syzbot reported a panic that looks like this:
assertion failed: fs_info->exclusive_operation == BTRFS_EXCLOP_BALANCE_PAUSED, in fs/btrfs/ioctl.c:465 ------------[ cut here ]------------ kernel BUG at fs/btrfs/messages.c:259! RIP: 0010:btrfs_assertfail+0x2c/0x30 fs/btrfs/messages.c:259 Call Trace:
btrfs_exclop_balance fs/btrfs/ioctl.c:465 [inline] btrfs_ioctl_balance fs/btrfs/ioctl.c:3564 [inline] btrfs_ioctl+0x531e/0x5b30 fs/btrfs/ioctl.c:4632 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x197/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd
The reproducer is running a balance and a cancel or pause in parallel. The way balance finishes is a bit wonky, if we were paused we need to save the balance_ctl in the fs_info, but clear it otherwise and cleanup. However we rely on the return values being specific errors, or having a cancel request or no pause request. If balance completes and returns 0, but we have a pause or cancel request we won't do the appropriate cleanup, and then the next time we try to start a balance we'll trip this ASSERT.
The error handling is just wrong here, we always want to clean up, unless we got -ECANCELLED and we set the appropriate pause flag in the exclusive op. With this patch the reproducer ran for an hour without tripping, previously it would trip in less than a few minutes.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
A race condition in btrfs balance operations can cause a kernel panic when balance and cancel/pause are run concurrently.
Vulnerability
A race condition exists in the Linux kernel's btrfs filesystem when balance operations are run concurrently with cancel or pause requests. The issue arises from flawed error handling in the balance completion path: when a balance operation finishes successfully (returns 0) but a concurrent pause or cancel request is pending, the cleanup logic is not executed correctly. This leaves the filesystem in an inconsistent state, specifically, the exclusive operation flag is not properly cleared or set to the paused state, leading to a subsequent assertion failure when another balance is attempted [1].
##
An attacker with local access and the ability to trigger btrfs ioctl calls (e.g., via unprivileged user namespaces or as a regular user with appropriate permissions) can exploit this race condition. The attack requires running a balance operation and simultaneously sending a cancel or pause ioctl. The race window is small but reproducible, as demonstrated by syzbot's reproducer [1]. No special privileges beyond those needed to invoke the relevant ioctls are required.
##
The impact is a kernel panic (BUG_ON) triggered by the assertion failure, resulting in a denial of service (DoS) for the entire system. The panic manifests as a crash with the message "assertion failed: fs_info->exclusive_operation == BTRANSACTION == BTRFS_EXCLOP_BALANCE_PAUSED" and a subsequent kernel BUG at fs/btrfs/messages.c:259 [1]. This can be used to crash a targeted system, disrupting availability.
##
The vulnerability is fixed in
Linux kernel commits b19c98f237cd and ddf7e8984c83, which correct the error handling to always perform cleanup regardless of the return value unless the operation was explicitly cancelled and the pause flag was set [1]. Users should apply the latest stable kernel updates to mitigate this issue.
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
1Patches
3ddf7e8984c8372efe5d44821b19c98f237cdVulnerability mechanics
Generated on May 9, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
3News mentions
0No linked articles in our index yet.