CVE-2026-90092 in Linux
Resumen
por VulDB • 2026-09-18
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
Bluetooth: L2CAP: rechazar la adición a la cola de aceptación (accept queue) salvo que esté en estado BT_LISTEN
No se debe añadir un nuevo sk a la cola de aceptación del socket padre después de que l2cap_sock_cleanup_listen() haya finalizado en l2cap_sock_teardown_cb() y el estado se haya establecido como BT_CLOSED, ya que esto puede provocar un Use-After-Free (UAF) al desreferenciar la referencia colgante del padre.
l2cap_sock_new_connection_cb() podría sufrir una condición de carrera con la destrucción del canal padre l2cap_chan, debido a que chan->state se accede sin un bloqueo consistente:
[Tarea 1] [Tarea 2]
l2cap_sock_release(parent) l2cap_connect l2cap_sock_shutdown pchan = l2cap_global_chan_by_psm l2cap_chan_lock(pchan) l2cap_chan_close l2cap_sock_teardown_cb pchan->state = BT_CLOSED l2cap_chan_unlock(pchan) ------> l2cap_chan_lock(pchan) l2cap_new_connection l2cap_sock_new_connection_cb l2cap_chan_lock(pchan) <-------- l2cap_chan_unlock(pchan) l2cap_sock_kill(parent) /* bt_sk(sk)->parent colgante */
La corrección consiste en añadir una comprobación de sk_state == BT_LISTEN después de adquirir el bloqueo del socket (sk lock) en l2cap_sock_new_connection_cb(). Se añade lock_sock() alrededor de las escrituras de sk_state donde faltaba, para evitar condiciones de carrera de datos.
Aunque también deberían corregirse las condiciones de carrera sobre pchan->state, esta comprobación defensiva de sk_state probablemente tiene sentido en cualquier caso.
If you want to get best quality of vulnerability data, you may have to visit VulDB.