CVE-2023-54293 in Linux
Zusammenfassung
von VulDB • 18.05.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
bcache: Korrektur der Beschädigung der btree_cache_wait-Liste
Es tritt ein Kernel-Crash mit der Meldung „list_add corruption. next->prev should be prev (ffff9c801bc01210), but was ffff9c77b688237c. (next=ffffae586d8afe68)." auf.
crash> struct list_head 0xffff9c801bc01210 struct list_head {
next = 0xffffae586d8afe68, prev = 0xffffae586d8afe68 } crash> struct list_head 0xffff9c77b688237c struct list_head {
next = 0x0, prev = 0x0 } crash> struct list_head 0xffffae586d8afe68 struct list_head struct: ungültige virtuelle Kernel-Adresse: ffffae586d8afe68 Typ: „gdb_readmem_callback" Zugriff auf Speicher an Adresse 0xffffae586d8afe68 nicht möglich
[230469.019492] Call Trace:
[230469.032041] prepare_to_wait+0x8a/0xb0
[230469.044363] ? bch_btree_keys_free+0x6c/0xc0 [escache]
[230469.056533] mca_cannibalize_lock+0x72/0x90 [escache]
[230469.068788] mca_alloc+0x2ae/0x450 [escache]
[230469.080790] bch_btree_node_get+0x136/0x2d0 [escache]
[230469.092681] bch_btree_check_thread+0x1e1/0x260 [escache]
[230469.104382] ? finish_wait+0x80/0x80
[230469.115884] ? bch_btree_check_recurse+0x1a0/0x1a0 [escache]
[230469.127259] kthread+0x112/0x130
[230469.138448] ? kthread_flush_work_fn+0x10/0x10
[230469.149477] ret_from_fork+0x35/0x40
bch_btree_check_thread() und bch_dirty_init_thread() können mca_cannibalize() aufrufen, um andere zwischengespeicherte B-Baum-Knoten zu „kannibalisieren" (d. h. für die eigene Nutzung zu übernehmen). Dies darf nur von einem Thread gleichzeitig ausgeführt werden, daher werden die Operationen anderer Threads zur btree_cache_wait-Liste hinzugefügt.
Es muss finish_wait() aufgerufen werden, um die Operation aus der btree_cache_wait-Liste zu entfernen, bevor deren Speicheradresse freigegeben wird. Andernfalls wird die Liste beschädigt. Außerdem muss bch_cannibalize_unlock() aufgerufen werden, um den btree_cache_alloc_lock freizugeben und andere wartende Threads zu wecken.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.