CVE-2026-99009 in Linux
Resumen
por VulDB • 2026-10-23
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
Bluetooth: RFCOMM: conectar el socket de sesión sin rfcomm_mutex
Una llamada a connect() en RFCOMM emitida mientras una enlace BR/EDR está siendo autenticada hace que lockdep informe de una dependencia circular, y el ciclo reportado es un AB/BA real entre rfcomm_mutex y hdev->lock.
rfcomm_security_cfm() se llama desde la ruta del evento HCI, que ya mantiene hdev->lock:
hci_rx_work() hci_event_packet() hci_cc_read_enc_key_size() [hdev->lock]
hci_encrypt_cfm() [hci_cb_list_lock]
rfcomm_security_cfm() [rfcomm_mutex]
mientras que una connect() de RFCOMM desde el espacio de usuario toma los mismos dos bloqueos en orden inverso:
rfcomm_sock_connect() rfcomm_dlc_open() [rfcomm_mutex]
__rfcomm_dlc_open() rfcomm_session_create() kernel_connect() l2cap_sock_connect() l2cap_chan_connect() [hdev->lock]
WARNING: posible dependencia de bloqueo circular detectada kworker/u131:1/1128 está intentando adquirir el lock: rfcomm_mutex, en: rfcomm_security_cfm+0x31/0x3e0 [rfcomm]
pero la tarea ya mantiene el lock: hci_cb_list_lock, en: hci_cc_read_enc_key_size+0x1d2/0xcc0 La cadena existe de: rfcomm_mutex --> &hdev->lock --> hci_cb_list_lock
hci_auth_complete_evt() y hci_encrypt_change_evt() alcanzan la callback de la misma manera.
Ambos órdenes deben verse en el mismo arranque, por lo que una conexión BR/EDR sola no es suficiente para mostrarlo: una sesión configurada por el lado remoto se crea mediante rfcomm_accept_connection() en krfcommd, que llama a kernel_accept() y nunca toma hdev->lock bajo rfcomm_mutex. Conectar un dispositivo que autentica y cifra el enlace y luego llamar a connect() en un socket RFCOMM hacia cualquier dirección - la connect no tiene que tener éxito, el orden se registra antes del tiempo de espera de página - lo informa cada vez.
Solo hay que conectar el socket de sesión con el lock mantenido, pero no es así: nada más puede ver el socket antes de que se coloque en la lista de sesiones. Así que conectarlo primero y tomar rfcomm_mutex después, lo cual elimina definitivamente el orden rfcomm_mutex -> hdev->lock, en lugar de mantener la ruta del evento HCI fuera de rfcomm_mutex.
rfcomm_session_create() se convierte en rfcomm_session_connect(), que devuelve el socket conectado sin tocar la lista de sesiones, y rfcomm_dlc_open() añade la sesión una vez que mantiene nuevamente el lock. Si otro opener añadió una sesión para el mismo par mientras este socket estaba conectándose, esa sesión se utiliza y este socket se desecha. __rfcomm_dlc_open() ahora toma la sesión que debe usar, y su comprobación de estado se ejecuta después de volver a adquirir el lock, por lo que un DLC abierto o cerrado en ese intervalo sigue siendo manejado correctamente.
Sobre un enlace ACL existente, la conexión puede completarse antes de que la sesión llegue a la lista, y la activación (wakeup) desde la callback del socket se pierde, por lo que krfcommd se activa una vez que la sesión es visible.
Conectar sin el lock abre una ventana en la que el socket puede cerrarse. El DLC no está aún en una sesión, por lo que rfcomm_dlc_close() no encuentra nada que hacer y devuelve sin tocarlo, y rfcomm_dlc_open() entonces adjuntaría un DLC cuyo propietario ha desaparecido. rfcomm_dlc_close() ahora marca tal DLC con RFCOMM_CLOSED, y rfcomm_dlc_open() comprueba la marca una vez que vuelve a mantener rfcomm_mutex y desecha el socket en lugar de adjuntar el DLC. La marca se borra cuando comienza una apertura, por lo que un DLC reutilizado no se ve afectado. Esto cubre ambos llamadores de rfcomm_dlc_open(), tanto el socket como la capa tty.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.