CVE-2023-54023

What it actually does

Race condition in Btrfs balance ioctl handling allows concurrent cancel or pause requests to bypass exclusive operation state cleanup when balance returns success, violating the BTRFS_EXCLOP_BALANCE_PAUSED assertion and triggering a kernel BUG/panic.

Why it matters to the business

Unprivileged local users can crash affected Linux systems running Btrfs, causing unplanned downtime, potential data inconsistency during recovery, and loss of availability for workloads relying on the filesystem.

How an attack unfolds

An attacker with local access starts a balance operation while simultaneously issuing cancel or pause requests. If balance completes and returns zero without proper error handling for the concurrent request, the exclusive operation flag is left in an inconsistent state; subsequent balance attempts hit the assertion failure and panic the kernel.

How to fix it

Upgrade to a kernel containing commit ddf7e8984c83aee9122552529f4e77291903f8d9 or later; apply distribution-specific Btrfs fixes; avoid running balance operations under concurrent cancel/pause workloads until patched; consider read-only mounts or alternative filesystems for high-risk systems.

How to confirm the fix worked

Confirm kernel source contains the referenced commit; test that parallel balance/cancel no longer triggers the assertion; monitor dmesg for absence of btrfs_assertfail messages after applying the fix.

Typical attack path

1. Obtain local unprivileged shell on target system with Btrfs volume
2. Issue parallel btrfs balance start and btrfs balance cancel/pause commands
3. Trigger completion path that returns 0 instead of expected error codes
4. Observe kernel panic from failed assertion in btrfs_exclop_balance

How to detect it

Search kernel logs for btrfs_assertfail or the exact assertion message regarding exclusive_operation; inspect audit logs for sequences of btrfs ioctl calls involving balance start followed immediately by cancel or pause; monitor for unexpected kernel oops or panic entries referencing fs/btrfs/ioctl.c.

What your security team should do

• Prioritize patching Btrfs-enabled kernels within maintenance windows due to local DoS risk
• Restrict unprivileged users from issuing btrfs ioctl balance commands via capabilities or SELinux/AppArmor policies
• Audit systems for Btrfs usage and schedule filesystem migration where feasible
• Enable kernel panic logging and watchdog timers to accelerate detection of triggered crashes