CVE-2026-53073

What it actually does

This is a Linux kernel race condition in the Bluetooth HCI UART line discipline path. If hci_register_dev() fails during hci_uart_register_dev(), the HCI_UART_PROTO_INIT state was not cleared before protocol close and cleanup. A concurrent or subsequent UART receive path could still enter the protocol-specific receive handler through hci_uart_tty_receive() after related resources were released or hu->hdev was set to NULL. The likely technical outcomes are kernel NULL-pointer dereference, use-after-free-style access, or kernel crash; depending on kernel configuration, protocol implementation, and timing, memory-safety side effects may be possible, but no public exploit maturity is reported.

Why it matters to the business

Systems using Linux Bluetooth over UART can become unstable or crash if the vulnerable race is triggered, causing service interruption, device reboot, or loss of Bluetooth functionality. The risk is most relevant to embedded Linux devices, IoT gateways, mobile/edge devices, industrial systems, and appliances that expose or depend on UART-attached Bluetooth controllers. Current exploitation likelihood appears low based on the low EPSS score, lack of KEV listing, lack of known ransomware use, and no reported public exploit, but kernel flaws should still be prioritized where Bluetooth UART is enabled in production or exposed to untrusted local/physical interaction.

How an attack unfolds

An attacker needs a way to influence a Bluetooth HCI UART device or the associated TTY/line-discipline flow. They attempt to create conditions where Bluetooth HCI device registration fails in hci_uart_register_dev(), then race incoming UART data so that hci_uart_tty_receive() dispatches to a protocol-specific receive function while cleanup is in progress or after resources have been freed. Because HCI_UART_PROTO_INIT remains set in the vulnerable path, the receive side may incorrectly believe the protocol is still initialized and access invalid state. In practical terms, exploitation is timing-sensitive and likely requires local, physical, peripheral, or privileged-adjacent access to the Bluetooth UART path; the most plausible result is denial of service through a kernel oops, panic, or device instability.

How to fix it

Apply the Linux kernel update or vendor backport that clears HCI_UART_PROTO_INIT under the appropriate write lock before calling the protocol close handler and nulling hu->hdev. Because no exact affected product list or fixed package versions were provided, use distribution, appliance, or device-vendor advisories to identify the first fixed kernel build for each platform. Where immediate patching is not possible, reduce exposure by disabling unused Bluetooth support, unloading or blacklisting relevant Bluetooth HCI UART modules where operationally safe, disabling access to UART-attached Bluetooth devices, and restricting local/physical access to device interfaces. Validate mitigations carefully on embedded or appliance systems because Bluetooth transport drivers may be required for normal operation.

How to confirm the fix worked

Confirm the running kernel includes the vendor fix for the Bluetooth hci_ldisc error path. Check the installed and booted kernel versions, not only the package cache, and verify that systems were rebooted into the patched kernel after update. Where source or vendor patch metadata is available, confirm the fix that clears HCI_UART_PROTO_INIT before proto->close() in the hci_uart_register_dev() failure path. Assess exposure by checking whether Bluetooth, HCI UART, or hci_uart-related modules are present and loaded, and whether the system uses UART-attached Bluetooth controllers. After patching or mitigation, monitor kernel logs while exercising Bluetooth initialization to ensure there are no hci_uart, hci_register_dev, NULL-pointer, use-after-free, KASAN, BUG, or panic messages.

Typical attack path

1. Gain local, physical, or peripheral-level ability to interact with a UART-attached Bluetooth controller or its TTY line discipline.
2. Trigger Bluetooth HCI UART initialization or registration activity.
3. Induce or wait for hci_register_dev() failure during hci_uart_register_dev().
4. Send or race incoming UART data while the error cleanup path is closing the protocol and clearing device state.
5. Cause hci_uart_tty_receive() to enter a protocol-specific recv handler using stale or NULL state.
6. Crash the kernel or disrupt Bluetooth/kernel operation; in less likely scenarios, attempt to shape memory state for broader memory-safety impact.

How to detect it

Look for evidence of kernel instability or Bluetooth HCI UART failures rather than expecting a single definitive exploit signature. Relevant sources include kernel logs, systemd journal, dmesg history, crash dumps, pstore/ramoops, kdump/vmcore artifacts, appliance diagnostic bundles, and EDR telemetry that records kernel panics or module activity. Search for crashes or warnings involving hci_uart_tty_receive(), hci_uart_register_dev(), hci_register_dev(), Bluetooth HCI UART registration, NULL-pointer dereference, use-after-free, KASAN, general protection fault, BUG, Oops, or kernel panic. Time-correlate these events with Bluetooth device attach/reset/init activity, TTY line-discipline changes, unexpected local access, peripheral insertion, UART traffic spikes, or repeated device reboots. Because this issue is not known to be exploited in the wild and has no public exploit maturity, detections should be treated as suspicious indicators requiring triage rather than proof of compromise.

• hci_uart_tty_receive
• hci_uart_register_dev
• hci_register_dev
• HCI_UART_PROTO_INIT
• Bluetooth: hci_uart
• Bluetooth: HCI UART
• Unable to handle kernel NULL pointer dereference
• BUG: kernel NULL pointer dereference
• BUG: unable to handle page fault
• general protection fault
• KASAN: use-after-free
• KASAN: null-ptr-deref
• kernel BUG at
• Oops:
• Kernel panic
• Call Trace:
• hci_uart
• btqca
• hci_bcm
• hci_ll
• hci_h5

What your security team should do

• Prioritize patching Linux systems that use UART-attached Bluetooth controllers, especially embedded, IoT, edge, mobile, appliance, and physically accessible systems.
• Inventory systems with Bluetooth HCI UART support enabled or hci_uart-related modules loaded to determine practical exposure.
• Apply vendor-supported kernel updates and reboot into the fixed kernel; do not rely on package installation alone.
• If patching is delayed, disable unused Bluetooth functionality or restrict access to UART/TTY interfaces associated with Bluetooth controllers where operationally feasible.
• Review kernel logs for Bluetooth HCI UART errors, kernel oopses, panics, NULL-pointer dereferences, KASAN reports, or crashes around Bluetooth initialization events.
• Treat exploitation likelihood as currently low, but monitor vendor advisories and threat intelligence because kernel race-condition exploitability can change as technical details become weaponized.