CVE-2026-23146

What it actually does

Race condition during hci_uart_set_proto allows a TTY write wakeup to schedule write_work before hu->priv is initialized by proto->open, causing NULL pointer dereference in hci_uart_write_work when proto->dequeue is called.

Why it matters to the business

Affected Linux systems using Bluetooth UART may experience kernel crashes or instability when Bluetooth initialization overlaps with TTY activity, leading to denial of service and operational disruption on devices relying on this driver.

How an attack unfolds

An attacker with local access triggers the race by initiating Bluetooth UART protocol registration while simultaneously causing a TTY write wakeup; this schedules deferred work that dereferences an uninitialized pointer before the protocol open completes, resulting in a kernel fault.

How to fix it

Upgrade the Linux kernel to a fixed version such as 5.10.249 or apply the commit b0a900939e7e4866d9b90e9112514b72c451e873 (or equivalent backports) that moves the HCI_UART_PROTO_INIT bit set after successful proto->open.

How to confirm the fix worked

Verify the running kernel contains the fix by checking the presence of the corrected ordering in hci_uart_set_proto or confirming the kernel version matches or exceeds the listed fixed releases; test Bluetooth UART initialization under load to ensure no crash occurs.

Typical attack path

1. Obtain local user or process execution on the target system
2. Load or trigger the hci_uart Bluetooth driver
3. Time a TTY write wakeup event during hci_uart_set_proto and hci_uart_register_dev
4. Cause hci_uart_write_work to execute before hu->priv initialization
5. Trigger NULL dereference via proto->dequeue access

How to detect it

Review kernel logs for NULL pointer dereference oops in hci_uart_write_work or hci_uart_dequeue during Bluetooth initialization; inspect dmesg and syslog for TTY wakeup and workqueue scheduling events around hci_uart activity.

What your security team should do

• Prioritize kernel updates on all systems exposing Bluetooth UART interfaces
• Restrict local access and Bluetooth driver loading where not required
• Monitor for kernel oops or Bluetooth-related crashes as indicators of exposure
• Apply the patch or updated kernel packages within standard maintenance windows given low exploitation likelihood