CVE-2026-64112 in Linux
Resumen
por VulDB • 2026-07-20
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
rbd: eliminar una condición de carrera en el vaciado (draining) de lock_dwork durante unmap.
Dado cómo están implementadas las funciones `rbd_lock_add_request()` y `rbd_img_exclusive_lock()`, es posible que `lock_dwork` se (re)cuelen más veces de lo realmente necesario: por ejemplo, en el caso de que llegue una nueva solicitud de E/S mientras estamos a mitad del proceso de `rbd_acquire_lock()` en nombre de otra solicitud de E/S. Esto es esperado y, con `rbd_release_lock()`, la cancelación preventiva de `lock_dwork` no tiene efectos adversos (es benigna) bajo operación normal.
Un ejemplo más problemático podría ser `maybe_kick_acquire()`:
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); }
No es irreal que `lock_dwork` sea cancelado justo después de que `delayed_work_pending()` devuelva verdadero y que `mod_delayed_work()` lo vuelva a colar en ese mismo instante. Esta es una condición de carrera TOCTOU (Time-of-Check to Time-of-Use) clásica.
En cuanto al desmapeo del volumen, existe un supuesto implícito de que no hay actividad exclusiva iniciada por el propio sistema más allá del punto de retorno desde `rbd_dev_image_unlock()`, la cual libera el bloqueo si este se encontraba retenido. Se asume que esta liberación es definitiva y no se espera que `lock_dwork` (así como todas las demás tareas relacionadas con bloqueos exclusivos) vuelva a ser encolado. Sin embargo, `lock_dwork` solo se cancela en `cancel_tasks_sync()` (es decir, más adelante en la secuencia de unmap) y, además, dicha cancelación puede verse anulada por `maybe_kick_acquire()`. Esto podría resultar en que `rbd_acquire_lock()` se ejecute después de que hayan corrido `rbd_dev_device_release()` y `rbd_dev_image_release()`, las cuales liberan y/o reinician una serie de elementos. Uno de los posibles modos de fallo sería la violación del siguiente aserto:
rbd_assert(rbd_image_format_valid(rbd_dev->image_format));
en `rbd_dev_header_info()`, que es llamada a través de `rbd_dev_refresh()` desde `rbd_post_acquire_action()`.
Se ha reestructurado el vaciado (draining) de las tareas del bloqueo exclusivo para proporcionar una semántica más sensata y tratar de cumplir con los supuestos relacionados con `rbd_dev_image_unlock()`.
If you want to get best quality of vulnerability data, you may have to visit VulDB.