You are viewing this page in an unauthorized frame window.
This is a potential security issue, you are being redirected to
https://nvd.nist.gov
An official website of the United States government
Official websites use .gov
A .gov website belongs to an official government organization in the United States.
Secure .gov websites use HTTPS
A lock () or https:// means you've safely connected to the .gov website. Share sensitive information only on official, secure websites.
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.
Metrics
NVD enrichment efforts reference publicly available information to associate
vector strings. CVSS information contributed by other sources is also
displayed.
By selecting these links, you will be leaving NIST webspace.
We have provided these links to other web sites because they
may have information that would be of interest to you. No
inferences should be drawn on account of other sites being
referenced, or not, from this page. There may be other web
sites that are more appropriate for your purpose. NIST does
not necessarily endorse the views expressed, or concur with
the facts presented on these sites. Further, NIST does not
endorse any commercial products that may be mentioned on
these sites. Please address comments about this page to [email protected].
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
Initial Analysis by NIST7/08/2026 10:46:18 AM
Action
Type
Old Value
New Value
Added
CWE
CWE-362
Added
CPE Configuration
OR
*cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 5.8.17 up to (excluding) 5.9
*cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 4.19.153 up to (excluding) 4.20
*cpe:2.3:o:linux:linux_kernel:7.1:rc1:*:*:*:*:*:*
*cpe:2.3:o:linux:linux_kernel:7.1:rc2:*:*:*:*:*:*
*cpe:2.3:o:linux:linux_kernel:7.1:rc3:*:*:*:*:*:*
*cpe:2.3:o:linux:linux_kernel:7.1:rc4:*:*:*:*:*:*
*cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 5.16 up to (excluding) 6.1.175
*cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 5.11 up to (excluding) 5.15.209
*cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 6.7 up to (excluding) 6.12.92
*cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 6.13 up to (excluding) 6.18.34
*cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 6.19 up to (excluding) 7.0.11
*cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 6.2 up to (excluding) 6.6.142
*cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 5.4.73 up to (excluding) 5.5
*cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 4.14.203 up to (excluding) 4.15
*cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* versions from (including) 5.9.2 up to (excluding) 5.10.258
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->c