CVE-2023-54293

What it actually does

Failure to call finish_wait before freeing memory in bch_btree_check_thread and bch_dirty_init_thread corrupts the btree_cache_wait list_head, causing use-after-free list damage and kernel crashes during mca_alloc and btree node operations in the escache module.

Why it matters to the business

Linux systems relying on bcache for block caching may suffer sudden kernel panics and reboots, resulting in unplanned downtime for storage-heavy workloads; the issue affects stable kernel trees but carries low exploitation probability and no ransomware association.

How an attack unfolds

A local attacker triggers concurrent btree cache check or dirty initialization threads that contend on the btree_cache_alloc_lock, causing mca_cannibalize to queue operations on btree_cache_wait; improper cleanup leaves dangling list pointers that later corrupt the list during prepare_to_wait, leading to a crash. No named threat actors or public exploits are associated with this flaw.

How to fix it

Upgrade the Linux kernel to a version containing commit bcb295778afda4f2feb0d3c0289a53fd43d5a3a6 (or the equivalent stable backport) which ensures finish_wait removes the operation from btree_cache_wait before freeing and releases the cannibalize lock.

How to confirm the fix worked

Confirm the running kernel contains the listed commit hash; reproduce bch_btree_check_thread and bch_dirty_init_thread concurrency while monitoring for list_add corruption messages; verify absence of crashes after the update.

Typical attack path

1. Gain local code execution on a bcache-enabled system
2. Induce concurrent bch_btree_check_thread or bch_dirty_init_thread activity
3. Force mca_cannibalize_lock contention to enqueue waiters on btree_cache_wait
4. Trigger memory free of a waiter without finish_wait or bch_cannibalize_unlock
5. Cause subsequent list traversal to dereference invalid pointers and panic

How to detect it

Search kernel logs and dmesg for "list_add corruption", "btree_cache_wait", prepare_to_wait traces involving escache, and mca_cannibalize_lock activity around the time of panics.

• list_add corruption. next->prev should be prev
• ffff9c801bc01210
• mca_cannibalize_lock
• bch_btree_check_thread
• btree_cache_wait

What your security team should do

• Prioritize kernel updates on all bcache-using hosts within standard patch cycles
• Add kernel log monitoring for "list_add corruption" and escache module traces
• Review bcache usage and consider alternative caching layers if updates are delayed
• Test the fixed kernel in staging environments that exercise btree cache paths