CVE-2026-63974

What it actually does

This is a race condition in the Linux kernel Bluetooth HCI synchronization path. During Bluetooth device close or reset, the kernel could drain the HCI device workqueue without consistently marking the command path as draining, allowing command timeout work to be queued while shutdown/reset handling is in progress. Under the CVSS model, an adjacent, unauthenticated attacker within Bluetooth radio range could potentially trigger the vulnerable state and cause high-impact compromise of confidentiality, integrity, and availability, which may include kernel instability, denial of service, or broader kernel-level impact depending on the reachable code path and kernel configuration.

Why it matters to the business

Systems with enabled Bluetooth on vulnerable Linux kernels may be exposed to attacks from nearby adversaries without requiring credentials or user interaction. The practical exposure is limited to Bluetooth proximity rather than internet-wide reach, and current exploit maturity is reported as none with low EPSS, but the high CVSS impact means successful exploitation could disrupt endpoints, embedded devices, kiosks, laptops, or operational systems that rely on Bluetooth or run in physically accessible locations.

How an attack unfolds

An attacker must be within Bluetooth/adjacent-network range of a vulnerable Linux system with Bluetooth enabled and reachable. They attempt to interact with the Bluetooth controller or protocol stack in a way that causes reset or close handling while HCI command processing is active. The vulnerable race occurs when the kernel drains the HCI device workqueue but does not set the command-drain state, allowing timeout work to be queued during teardown. By repeatedly manipulating timing around Bluetooth operations, an attacker may trigger inconsistent kernel state, resulting in a crash, denial of service, or potentially more severe kernel-level effects. No public exploit maturity is currently indicated, and the issue is not listed in CISA KEV at this time.

How to fix it

Apply vendor-provided Linux kernel updates that include the Bluetooth HCI synchronization fix which sets HCI_CMD_DRAIN_WORKQUEUE during hci_dev_close_sync(). If a fixed kernel package is not yet available, reduce exposure by disabling Bluetooth where it is not required, blocking automatic Bluetooth discovery/pairing, limiting physical proximity to sensitive systems, and applying distribution kernel live patches or backported security updates when released. Prioritize laptops, workstations, embedded Linux devices, and systems in public or semi-public spaces where an adjacent attacker can get within Bluetooth range.

How to confirm the fix worked

Confirm the running kernel version includes the vendor fix for the Bluetooth hci_sync close/reset race. Validate both the installed package version and the actively running kernel after reboot, because updating the package alone is insufficient if the system has not booted into the fixed kernel. Where source validation is possible, confirm the Bluetooth HCI close/reset path sets HCI_CMD_DRAIN_WORKQUEUE during hci_dev_close_sync(). Also verify Bluetooth exposure by checking whether Bluetooth controllers are present, powered, and discoverable on systems where the service is not required.

Typical attack path

1. Identify a Linux device with Bluetooth enabled and within radio range.
2. Initiate Bluetooth interactions that reach the kernel HCI command handling path.
3. Trigger or influence conditions that cause Bluetooth device reset or close processing.
4. Race HCI command timeout queuing against workqueue draining during close/reset handling.
5. Cause kernel instability, service disruption, or potentially higher-impact kernel compromise depending on exploitability and kernel build.

How to detect it

Look for signs of abnormal Bluetooth HCI behavior before patching, especially repeated command timeouts, controller resets, device close/open cycles, kernel warnings, soft lockups, panics, or crashes involving the Bluetooth stack. Useful log sources include kernel ring buffer output, system journal kernel logs, syslog/kern.log, crash dumps, endpoint telemetry, and Bluetooth daemon logs. Focus searches around periods where devices were in public or physically accessible locations and correlate Bluetooth errors with unexpected reboots, kernel oops events, or loss of connectivity. Because exploitation depends on race timing and may leave only generic kernel/Bluetooth instability artifacts, absence of logs does not prove absence of exploitation.

• Bluetooth: hci0: command
• Bluetooth: hci0: Opcode
• tx timeout
• command tx timeout
• Bluetooth: hci0: Reset
• Bluetooth: hci0: hardware error
• Bluetooth: hci0: unexpected event
• hci_dev_close_sync
• hci_sync
• HCI_CMD_DRAIN_WORKQUEUE
• kernel BUG
• kernel panic
• Oops:
• soft lockup
• hung task
• bluetoothd

What your security team should do

• Inventory Linux systems with Bluetooth hardware or enabled Bluetooth services, prioritizing mobile endpoints, kiosks, embedded devices, and physically accessible systems.
• Patch affected Linux kernels as soon as vendor updates are available, and ensure systems reboot into the fixed kernel.
• Disable Bluetooth on systems that do not require it, especially servers and high-value endpoints.
• Monitor kernel and Bluetooth logs for HCI command timeouts, controller resets, kernel warnings, crashes, or repeated Bluetooth reconnect/reset activity.
• Treat unexplained kernel panics or Bluetooth subsystem instability on exposed systems as potentially security-relevant until patched and reviewed.
• Because the issue is not currently in KEV and EPSS is low, prioritize based on Bluetooth exposure and physical accessibility rather than internet-facing asset priority.