In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_uart: fix UAFs and race conditions in close and init paths Vulnerabilities leading to Use-After-Free (UAF) and Null Pointer Dereference (NPD) conditions were observed in the lifecycle management of hci_uart. The primary issue arises because the workqueues (init_ready and write_work) are only flushed/cancelled if the HCI_UART_PROTO_READY flag is set during TTY close. If a hangup occurs before setup completes, hci_uart_tty_close() skips the teardown of these workqueues and proceeds to free the `hu` struct. When the scheduled work executes later, it blindly dereferences the freed `hu` struct. Furthermore, several data races and UAFs were identified in the teardown sequence: 1. Calling hci_uart_flush() from hci_uart_close() without effectively disabling write_work causes a race condition where both can concurrently double-free hu->tx_skb. This happens because protocol timers can concurrently invoke hci_uart_tx_wakeup() and requeue write_work. 2. Calling hci_free_dev(hdev) before hu->proto->close(hu) causes a UAF when vendor specific protocol close callbacks dereference hu->hdev. 3. In the initialization error paths, failing to take the proto_lock write lock before clearing PROTO_READY leads to races with active readers. Additionally, hci_uart_tty_receive() accesses hu->hdev outside the read lock, leading to UAFs if the initialization error path frees hdev concurrently. Fix these synchronization and lifecycle issues by: 1. Re-ordering hci_uart_tty_close() to clear HCI_UART_PROTO_READY first, followed immediately by a cancel_work_sync(&hu->write_work). Clearing the flag locks out concurrent protocol timers from successfully invoking hci_uart_tx_wakeup(), effectively rendering the cancellation permanent and preventing the tx_skb double-free. 2. Note: Clearing PROTO_READY early causes hci_uart_close() to skip hu->proto->flush(). This is perfectly safe in the tty_close path because hu->proto->close() executes shortly after, which intrinsically purges all protocol SKB queues and tears down the state. 3. Relocating hu->proto->close(hu) strictly prior to hci_free_dev(hdev) across all close and error paths to prevent vendor-level UAFs. 4. Moving the hdev->stat.byte_rx increment in hci_uart_tty_receive() inside the proto_lock read-side critical section to safely synchronize with device unregistration. 5. Adding cancel_work_sync(&hu->write_work) to hci_uart_close() to safely flush the workqueue before hci_uart_flush() is invoked via the HCI core. 6. Utilizing cancel_work_sync() instead of disable_work_sync() across all paths to prevent permanently breaking user-space retry capabilities.
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.
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
| Attack Vector | LOCAL |
|---|---|
| Attack Complexity | LOW |
| Privileges Required | LOW |
| User Interaction | NONE |
| Scope | UNCHANGED |
| Confidentiality Impact | HIGH |
| Integrity Impact | HIGH |
| Availability Impact | HIGH |
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Type: Secondary
Exploitability Score: 1.8
Impact Score: 5.9
| Source | Type | Description |
|---|---|---|
| [email protected] | Primary |
en
CWE-362
|
| Vendor | Product | Version | Update | Type |
|---|---|---|---|---|
| linux | linux_kernel | * | <built-in method update of dict object at 0x7fd31b20f7c0> | Operating System |
| linux | linux_kernel | * | <built-in method update of dict object at 0x7fd31b20eb80> | Operating System |
| linux | linux_kernel | * | <built-in method update of dict object at 0x7fd38541d280> | Operating System |
| linux | linux_kernel | * | <built-in method update of dict object at 0x7fd368533cc0> | Operating System |
| linux | linux_kernel | * | <built-in method update of dict object at 0x7fd31b20d7c0> | Operating System |
| linux | linux_kernel | * | <built-in method update of dict object at 0x7fd31b20f640> | Operating System |
| linux | linux_kernel | * | <built-in method update of dict object at 0x7fd31b20ca80> | Operating System |
| linux | linux_kernel | * | <built-in method update of dict object at 0x7fd348ef2c40> | Operating System |
| linux | linux_kernel | * | <built-in method update of dict object at 0x7fd38541c780> | Operating System |
| linux | linux_kernel | * | <built-in method update of dict object at 0x7fd31b20fbc0> | Operating System |
| linux | linux_kernel | * | <built-in method update of dict object at 0x7fd36b7d7b80> | Operating System |
| linux | linux_kernel | 7.1 | <built-in method update of dict object at 0x7fd31b20d140> | Operating System |
| linux | linux_kernel | 7.1 | <built-in method update of dict object at 0x7fd31b20f000> | Operating System |
| linux | linux_kernel | 7.1 | <built-in method update of dict object at 0x7fd31b20c040> | Operating System |
| linux | linux_kernel | 7.1 | <built-in method update of dict object at 0x7fd34b9c2780> | Operating System |
| Vulnerable | CPE |
|---|---|
| Yes | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* |
| Yes | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* |
| Yes | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* |
| Yes | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* |
| Yes | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* |
| Yes | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* |
| Yes | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* |
| Yes | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* |
| Yes | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* |
| Yes | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* |
| Yes | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* |
| Yes | cpe:2.3:o:linux:linux_kernel:7.1:rc1:*:*:*:*:*:* |
| Yes | cpe:2.3:o:linux:linux_kernel:7.1:rc2:*:*:*:*:*:* |
| Yes | cpe:2.3:o:linux:linux_kernel:7.1:rc3:*:*:*:*:*:* |
| Yes | cpe:2.3:o:linux:linux_kernel:7.1:rc4:*:*:*:*:*:* |