U.S. flag   An official website of the United States government
Dot gov

Official websites use .gov
A .gov website belongs to an official government organization in the United States.

Https

Secure .gov websites use HTTPS
A lock (Dot gov) or https:// means you've safely connected to the .gov website. Share sensitive information only on official, secure websites.

Vulnerability Change Records for CVE-2026-46275

Change History

CVE Translated by NIST 7/23/2026 3:10:00 AM

Action Type Old Value New Value
Added Translation

                  
                
              
Title: Linux, Description: En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:

Bluetooth: hci_uart: corrige UAFs y condiciones de carrera en las rutas de cierre e inicialización

Se observaron vulnerabilidades que conducen a condiciones de Uso Después de Liberación (UAF) y Desreferencia de Puntero Nulo (NPD) en la gestión del ciclo de vida de hci_uart.

El problema principal surge porque las colas de trabajo (workqueues) (init_ready y write_work) solo se vacían/cancelan si la bandera HCI_UART_PROTO_READY está establecida durante el cierre de TTY. Si ocurre un cuelgue antes de que se complete la configuración, hci_uart_tty_close() omite la desinstalación de estas colas de trabajo y procede a liberar la estructura 'hu'. Cuando el trabajo programado se ejecuta más tarde, desreferencia ciegamente la estructura 'hu' liberada.

Además, se identificaron varias condiciones de carrera de datos y UAFs en la secuencia de desinstalación:
1. Llamar a hci_uart_flush() desde hci_uart_close() sin deshabilitar efectivamente write_work causa una condición de carrera donde ambos pueden liberar doblemente hu->tx_skb de forma concurrente. Esto sucede porque los temporizadores del protocolo pueden invocar concurrentemente hci_uart_tx_wakeup() y volver a encolar write_work.
2. Llamar a hci_free_dev(hdev) antes de hu->proto->close(hu) causa un UAF cuando las devoluciones de llamada de cierre del protocolo específico del proveedor desreferencian hu->hdev.
3. En las rutas de error de inicialización, no tomar el bloqueo de escritura proto_lock antes de borrar PROTO_READY conduce a condiciones de carrera con lectores activos. Además, hci_uart_tty_receive() accede a hu->hdev fuera del bloqueo de lectura, lo que lleva a UAFs si la ruta de error de inicialización libera hdev concurrentemente.

Corregir estos problemas de sincronización y ciclo de vida mediante:
1. Reordenar hci_uart_tty_close() para borrar HCI_UART_PROTO_READY primero, seguido inmediatamente por un cancel_work_sync(&hu->write_work). Borrar la bandera bloquea a los temporizadores del protocolo concurrentes para que no invoquen con éxito hci_uart_tx_wakeup(), haciendo que la cancelación sea permanente y evitando la doble liberación de tx_skb.
2. Nota: Borrar PROTO_READY temprano hace que hci_uart_close() omita hu->proto->flush(). Esto es perfectamente seguro en la ruta tty_close porque hu->proto->close() se ejecuta poco después, lo que intrínsecamente purga todas las colas SKB del protocolo y desinstala el estado.
3. Reubicar hu->proto->close(hu) estrictamente antes de hci_free_dev(hdev) en todas las rutas de cierre y error para prevenir UAFs a nivel de proveedor.
4. Mover el incremento de hdev->stat.byte_rx en hci_uart_tty_receive() dentro de la sección crítica del lado de lectura de proto_lock para sincronizar de forma segura con la anulación del registro del dispositivo.
5. Añadir cancel_work_sync(&hu->write_work) a hci_uart_close() para vaciar de forma segura la cola de trabajo antes de que hci_uart_flush() sea invocado a través del núcleo HCI.
6. Utilizar cancel_work_sync() en lugar de disable_work_sync() en todas las rutas para evitar romper permanentemente las capacidades de reintento del espacio de usuario.