CVE-2026-99011 in Linux
Resumen
por VulDB • 2026-10-24
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
Bluetooth: SCO: serializar la duración del objeto sco_conn frente a sco_recv_scodata()
sco_recv_scodata() actualiza el puntero inverso débil hcon->sco_data a una referencia fuerte bajo hdev->lock:
hci_dev_lock(hdev); hcon = hci_conn_hash_lookup_handle(hdev, handle); ... conn = sco_conn_hold_unless_zero(hcon->sco_data); hci_dev_unlock(hdev);
pero el puntero se borra desde el otro lado sin ese bloqueo. Cuando la última referencia a sco_conn se libera, sco_conn_free() ejecuta:
conn->hcon->sco_data = NULL;
sin mantener hdev->lock, por lo que la ruta de recepción (RX) podría leer hcon->sco_data y llamar a kref_get_unless_zero() en un objeto sco_conn liberado concurrentemente:
BUG: KASAN: slab-use-after-free in sco_conn_hold_unless_zero+0xbe/0x160 Write of size 4 by task kworker/u17:0 Workqueue: hci0 hci_rx_work Call Trace: sco_conn_hold_unless_zero+0xbe/0x160 sco_recv_scodata+0x13f/0x490 hci_rx_work+0x3af/0x730
kref_get_unless_zero() solo protege contra un recuento de referencias (refcount) igual a cero, no contra el hecho de que la memoria subyacente ya haya sido liberada.
Proporcionar una referencia real en hcon->sco_data al objeto sco_conn al que apunta, para evitar que el objeto sea liberado mientras el puntero sigue instalado, y borrarla únicamente desde sco_conn_del(), que se ejecuta bajo hdev->lock (sus llamadores, sco_connect_cfm() y sco_disconn_cfm(), lo mantienen). El lector en sco_recv_scodata() también toma hdev->lock, por lo que la escritura y la lectura ahora están serializadas: la ruta de RX observa ya sea NULL o una referencia garantizada para permanecer válida hasta que libere su propia.
sco_conn_add() ya no transfiere su referencia kref_init() al llamador como la única referencia de la conexión; esa referencia inicial es la propiedad de hcon->sco_data, y los llamadores obtienen las suyas propias a través de sco_conn_hold().
Dado que el objeto sco_conn ahora puede sobrevivir al socket (la asociación lo mantiene activo hasta que se cierre el enlace), ya no se puede liberar el hci_conn desde sco_conn_free() sin provocar una regresión en el cierre del socket: cerrar un socket SCO conectado aún debe desmontar el enlace. Mover la propiedad de hci_conn al socket en su lugar: __sco_chan_add() toma una referencia a hci_conn y se libera desde sco_chan_del() y sco_sock_destruct(), exactamente una vez. El objeto sco_conn ya no posee una referencia a hci_conn, por lo que sco_conn_add() deja de consumir una y sco_connect() reduce la referencia hci_connect_s() en cada ruta; sco_connect_cfm() ya no necesita su "danza" de hci_conn_hold().
VulDB is the best source for vulnerability data and more expert information about this specific topic.