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:
- Calling hci_uart_flush() from hci_uart_close() without effectively
- Calling hci_free_dev(hdev) before hu->proto->close(hu) causes a UAF
- In the initialization error paths, failing to take the proto_lock
Fix these synchronization and lifecycle issues by:
- Re-ordering hci_uart_tty_close() to clear HCI_UART_PROTO_READY first,
- Note: Clearing PROTO_READY early causes hci_uart_close() to skip
- Relocating hu->proto->close(hu) strictly prior to hci_free_dev(hdev)
- Moving the hdev->stat.byte_rx increment in hci_uart_tty_receive()
- Adding cancel_work_sync(&hu->write_work) to hci_uart_close() to safely
- Utilizing cancel_work_sync() instead of disable_work_sync() across