CVE-2026-23146: Bluetooth: hci_uart: fix null-ptr-deref in hci_uart_write_work
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hciuart: fix null-ptr-deref in hciuartwritework
hciuartsetproto() sets HCIUARTPROTOINIT before calling hciuartregisterdev(), which calls proto->open() to initialize hu->priv. However, if a TTY write wakeup occurs during this window, hciuarttxwakeup() may schedule writework before hu->priv is initialized, leading to a NULL pointer dereference in hciuartwritework() when proto->dequeue() accesses hu->priv.
The race condition is:
CPU0 CPU1 ---- ---- hciuartsetproto() setbit(HCIUARTPROTOINIT) hciuartregisterdev() tty write wakeup hciuartttywakeup() hciuarttxwakeup() schedulework(&hu->writework) proto->open(hu) // initializes hu->priv hciuartwritework() hciuartdequeue() proto->dequeue(hu) // accesses hu->priv (NULL!)
Fix this by moving setbit(HCIUARTPROTOINIT) after proto->open() succeeds, ensuring hu->priv is initialized before any work can be scheduled.
Affected Software
Event History
Frequently Asked Questions
Who is realistically exposed to this issue?
Systems using the Linux kernel Bluetooth HCI UART path are exposed during HCI UART protocol setup. Exploitation requires local access with low privileges; the CVSS vector does not indicate network or user-interaction requirements.
What conditions trigger the crash?
A TTY write wakeup must occur after HCI_UART_PROTO_INIT is set but before the protocol open operation initializes hu->priv. The resulting scheduled write work can call the protocol dequeue operation with hu->priv still NULL, causing a denial of service.
What does the fix change?
The fix delays setting HCI_UART_PROTO_INIT until after proto->open() succeeds. This prevents write work from being scheduled before the protocol-private state has been initialized.