AZL-89600

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 (initready and writework) are only flushed/cancelled if the HCIUARTPROTOREADY flag is set during TTY close. If a hangup occurs before setup completes, hciuartttyclose() 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 hciuartflush() from hciuartclose() without effectively disabling writework causes a race condition where both can concurrently double-free hu->txskb. This happens because protocol timers can concurrently invoke hciuarttxwakeup() and requeue writework. 2. Calling hcifreedev(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 protolock write lock before clearing PROTOREADY leads to races with active readers. Additionally, hciuarttty_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 hciuartttyclose() to clear HCIUARTPROTOREADY first, followed immediately by a cancelworksync(&hu->writework). Clearing the flag locks out concurrent protocol timers from successfully invoking hciuarttxwakeup(), effectively rendering the cancellation permanent and preventing the txskb double-free. 2. Note: Clearing PROTOREADY early causes hciuartclose() to skip hu->proto->flush(). This is perfectly safe in the ttyclose 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 hcifreedev(hdev) across all close and error paths to prevent vendor-level UAFs. 4. Moving the hdev->stat.byterx increment in hciuartttyreceive() inside the protolock read-side critical section to safely synchronize with device unregistration. 5. Adding cancelworksync(&hu->writework) to hciuartclose() to safely flush the workqueue before hciuartflush() is invoked via the HCI core. 6. Utilizing cancelworksync() instead of disablework_sync() across all paths to prevent permanently breaking user-space retry capabilities.