Vulnerabilidad en Linux (CVE-2026-46275)

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> Bluetooth: hci_uart: corrige UAFs y condiciones de carrera en las rutas de cierre e inicialización<br /> <br /> 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.<br /> <br /> 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 &amp;#39;hu&amp;#39;. Cuando el trabajo programado se ejecuta más tarde, desreferencia ciegamente la estructura &amp;#39;hu&amp;#39; liberada.<br /> <br /> Además, se identificaron varias condiciones de carrera de datos y UAFs en la secuencia de desinstalación:<br /> 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-&gt;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.<br /> 2. Llamar a hci_free_dev(hdev) antes de hu-&gt;proto-&gt;close(hu) causa un UAF cuando las devoluciones de llamada de cierre del protocolo específico del proveedor desreferencian hu-&gt;hdev.<br /> 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-&gt;hdev fuera del bloqueo de lectura, lo que lleva a UAFs si la ruta de error de inicialización libera hdev concurrentemente.<br /> <br /> Corregir estos problemas de sincronización y ciclo de vida mediante:<br /> 1. Reordenar hci_uart_tty_close() para borrar HCI_UART_PROTO_READY primero, seguido inmediatamente por un cancel_work_sync(&amp;hu-&gt;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.<br /> 2. Nota: Borrar PROTO_READY temprano hace que hci_uart_close() omita hu-&gt;proto-&gt;flush(). Esto es perfectamente seguro en la ruta tty_close porque hu-&gt;proto-&gt;close() se ejecuta poco después, lo que intrínsecamente purga todas las colas SKB del protocolo y desinstala el estado.<br /> 3. Reubicar hu-&gt;proto-&gt;close(hu) estrictamente antes de hci_free_dev(hdev) en todas las rutas de cierre y error para prevenir UAFs a nivel de proveedor.<br /> 4. Mover el incremento de hdev-&gt;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.<br /> 5. Añadir cancel_work_sync(&amp;hu-&gt;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.<br /> 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.