CVE-2026-64112 in Linux
Zusammenfassung
von VulDB • 19.07.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
rbd: Behebung einer Race-Bedingung beim Abfluss von lock_dwork während des Unmap-Vorgangs
Aufgrund der Implementierung von `rbd_lock_add_request()` und `rbd_img_exclusive_lock()` kann `lock_dwork` häufiger (neu) geplant werden, als tatsächlich erforderlich ist. Ein Beispiel hierfür liegt vor, wenn ein neuer I/O-Anforderungseingang erfolgt, während wir uns mitten in einem Aufruf von `rbd_acquire_lock()` im Auftrag einer anderen I/O-Anforderung befinden. Dies ist erwartbar und unter normalen Betriebsbedingungen harmlos, da durch `rbd_release_lock()` das Abbrechen von `lock_dwork` präventiv erfolgt.
Ein problematischeres Beispiel stellt möglicherweise `maybe_kick_acquire()` dar:
if (have_requests || delayed_work_pending(&rbd_dev->lock_dwork)) {
dout("%s rbd_dev %p kicking lock_dwork\n", __func__, rbd_dev); mod_delayed_work(rbd_dev->task_wq, &rbd_dev->lock_dwork, 0); }
Es ist nicht unrealistisch, dass `lock_dwork` direkt nach dem Rückgabewert von `delayed_work_pending()` (true) abgebrochen wird und `mod_delayed_work()` es dennoch sofort wieder einplant. Dies stellt eine klassische TOCTOU-Race-Bedingung dar.
Beim Unmapen des Abbilds besteht die implizite Annahme, dass keine selbst initiierten exklusiven Sperraktivitäten nach dem Rückgabewert von `rbd_dev_image_unlock()` stattfinden, welches die Sperre freigibt, falls sie gehalten wird. Diese Freigabe gilt als endgültig, und es wird nicht erwartet, dass `lock_dwork` (sowie alle anderen Aufgaben für exklusive Sperren) erneut eingeplant wird. Allerdings wird `lock_dwork` erst in `cancel_tasks_sync()` abgebrochen (also später im Unmap-Ablauf), und zudem kann das Abbrechen durch `maybe_kick_acquire()` effektiv aufgehoben werden. Dies kann dazu führen, dass `rbd_acquire_lock()` ausgeführt wird, nachdem `rbd_dev_device_release()` und `rbd_dev_image_release()` bereits gelaufen sind und eine Reihe von Dingen freigegeben und/oder zurückgesetzt haben. Eine der möglichen Fehlerursachen ist dann ein verletztes
rbd_assert(rbd_image_format_valid(rbd_dev->image_format));
in `rbd_dev_header_info()`, das über `rbd_dev_refresh()` aus `rbd_post_acquire_action()` aufgerufen wird.
Das Abfließen von Aufgaben für exklusive Sperren wurde neu implementiert, um sinnvollere Semantik bereitzustellen und die Annahmen im Zusammenhang mit `rbd_dev_image_unlock()` zu erfüllen.
If you want to get best quality of vulnerability data, you may have to visit VulDB.