PT-2026-47327 · Linux · Linux

Published

2026-06-08

·

Updated

2026-06-08

·

CVE-2026-46275

None

No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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.

Related Identifiers

CVE-2026-46275

Affected Products

Linux