Monitor vulnerabilities like this one.
Sign up free to get alerted when software you use is affected.
Linux Bluetooth: Uninitialized Data Causes Crash During TTY Write
CVE-2026-23146
Summary
A bug in the Linux Bluetooth driver could cause the system to crash when a certain type of data is written to a TTY. This has been fixed in a recent update. To stay safe, make sure you have the latest version of the Linux kernel installed.
Original title
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_uart: fix null-ptr-deref in hci_uart_write_work
hci_uart_set_proto() sets HCI_UART_PROTO_INIT before calling
hci...
Original description
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_uart: fix null-ptr-deref in hci_uart_write_work
hci_uart_set_proto() sets HCI_UART_PROTO_INIT before calling
hci_uart_register_dev(), which calls proto->open() to initialize
hu->priv. However, if a TTY write wakeup occurs during this window,
hci_uart_tx_wakeup() may schedule write_work before hu->priv is
initialized, leading to a NULL pointer dereference in
hci_uart_write_work() when proto->dequeue() accesses hu->priv.
The race condition is:
CPU0 CPU1
---- ----
hci_uart_set_proto()
set_bit(HCI_UART_PROTO_INIT)
hci_uart_register_dev()
tty write wakeup
hci_uart_tty_wakeup()
hci_uart_tx_wakeup()
schedule_work(&hu->write_work)
proto->open(hu)
// initializes hu->priv
hci_uart_write_work()
hci_uart_dequeue()
proto->dequeue(hu)
// accesses hu->priv (NULL!)
Fix this by moving set_bit(HCI_UART_PROTO_INIT) after proto->open()
succeeds, ensuring hu->priv is initialized before any work can be
scheduled.
Bluetooth: hci_uart: fix null-ptr-deref in hci_uart_write_work
hci_uart_set_proto() sets HCI_UART_PROTO_INIT before calling
hci_uart_register_dev(), which calls proto->open() to initialize
hu->priv. However, if a TTY write wakeup occurs during this window,
hci_uart_tx_wakeup() may schedule write_work before hu->priv is
initialized, leading to a NULL pointer dereference in
hci_uart_write_work() when proto->dequeue() accesses hu->priv.
The race condition is:
CPU0 CPU1
---- ----
hci_uart_set_proto()
set_bit(HCI_UART_PROTO_INIT)
hci_uart_register_dev()
tty write wakeup
hci_uart_tty_wakeup()
hci_uart_tx_wakeup()
schedule_work(&hu->write_work)
proto->open(hu)
// initializes hu->priv
hci_uart_write_work()
hci_uart_dequeue()
proto->dequeue(hu)
// accesses hu->priv (NULL!)
Fix this by moving set_bit(HCI_UART_PROTO_INIT) after proto->open()
succeeds, ensuring hu->priv is initialized before any work can be
scheduled.
- https://git.kernel.org/stable/c/03e8c90c62233382042b7bd0fa8b8900552fdb62
- https://git.kernel.org/stable/c/0c3cd7a0b862c37acbee6d9502107146cc944398
- https://git.kernel.org/stable/c/186d147cf7689ba1f9b3ddb753ab634a84940cc9
- https://git.kernel.org/stable/c/53e54cb31e667fca05b1808b990eac0807d1dab0
- https://git.kernel.org/stable/c/937a573423ce5a96fdb1fd425dc6b8d8d4ab5779
- https://git.kernel.org/stable/c/b0a900939e7e4866d9b90e9112514b72c451e873
- https://git.kernel.org/stable/c/ccc683f597ceb28deb966427ae948e5ac739a909
Published: 14 Feb 2026 · Updated: 10 Mar 2026 · First seen: 6 Mar 2026