CVE-2026-64405

What it actually does

CVE-2026-64405 is a Linux kernel Bluetooth stack flaw in the HCI connection handling path. When a Bluetooth connection is pending, hci_abort_conn() can dereference hdev->sent_cmd even when that pointer is NULL while the request state still indicates HCI_REQ_PEND. This can cause a NULL pointer dereference/general protection fault in the hci_rx_work() receive worker, typically resulting in a kernel oops, Bluetooth subsystem disruption, or system crash depending on kernel panic settings. The resolved kernel change avoids inspecting the potentially NULL sent_cmd pointer and instead tracks in-flight create-connection operations with per-connection flags and synchronized cancellation logic.

Why it matters to the business

Systems with Bluetooth enabled may be susceptible to denial of service if the vulnerable kernel Bluetooth code path is triggered. The most likely operational impact is loss of Bluetooth functionality or an unexpected host crash/reboot, which can affect laptops, workstations, embedded Linux devices, kiosks, industrial tablets, IoT gateways, and other Linux-based systems that rely on Bluetooth peripherals or wireless device connectivity. The EPSS score is low and there is no known CISA KEV listing or known ransomware use, so broad exploitation urgency is lower than for actively exploited remote-code-execution issues, but patching is still important for exposed or mission-critical Bluetooth-enabled Linux assets.

How an attack unfolds

An attacker would need to cause vulnerable Bluetooth connection-management behavior on a Linux system with Bluetooth enabled. In a plausible scenario, the attacker operates from Bluetooth radio range or otherwise influences Bluetooth HCI events, induces or races a pending connection attempt, and causes the kernel to enter the abort/cancel path while the request state remains pending but hdev->sent_cmd is NULL. When the Bluetooth receive worker processes the relevant event path, hci_abort_conn() dereferences the NULL pointer, producing a general protection fault or kernel oops. Successful exploitation is expected to produce denial of service rather than direct code execution.

How to fix it

Apply a Linux kernel update that includes the upstream Bluetooth hci_conn fix for hci_abort_conn() NULL pointer dereference handling. Because no product-specific fixed versions were provided, obtain patched kernels from the relevant Linux distribution, appliance vendor, or embedded device supplier and prioritize systems where Bluetooth is enabled or operationally required. If immediate patching is not possible, reduce exposure by disabling Bluetooth adapters and services on systems that do not require them, blocking untrusted physical/radio access where feasible, removing or blacklisting Bluetooth kernel modules only where operationally safe, and applying vendor-recommended kernel live patches if available. Reboot systems after kernel updates unless the vendor explicitly supports live patching for this fix.

How to confirm the fix worked

Confirm the running kernel version includes the vendor fix for the Bluetooth hci_conn/hci_abort_conn issue. Validate both the installed kernel package and the active booted kernel, because Linux systems often retain older kernels until reboot. Check whether Bluetooth is enabled and whether Bluetooth kernel modules are loaded. After remediation, review vendor advisories or kernel changelogs for references to the hci_abort_conn(), hci_cancel_connect_sync(), HCI_CONN_CREATE, or NULL pointer dereference fix. Where appropriate, perform controlled Bluetooth connection and disconnection testing to confirm normal operation and absence of new kernel oops messages.

Typical attack path

1. Identify a Linux system with Bluetooth enabled and using a vulnerable kernel build.
2. Get within Bluetooth radio range or otherwise gain the ability to influence Bluetooth connection attempts or HCI event flow.
3. Trigger or induce a pending Bluetooth connection creation state.
4. Cause the connection to be aborted/cancelled while the vulnerable state mismatch exists: req_status remains HCI_REQ_PEND while hdev->sent_cmd is NULL.
5. The kernel Bluetooth receive worker enters hci_abort_conn() and dereferences the NULL pointer.
6. The host experiences a kernel oops, general protection fault, Bluetooth stack failure, or crash/reboot depending on system configuration.

How to detect it

To determine whether exploitation or triggering has already occurred, review kernel and system logs for Bluetooth-related crashes, oops reports, NULL pointer dereferences, and general protection faults. Useful log sources include journalctl kernel logs, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dump tooling such as kdump/vmcore, apport/ABRT reports, endpoint telemetry, and EDR records of unexpected reboots. Focus searches around Bluetooth HCI receive/connection handling symbols including hci_abort_conn(), hci_rx_work(), hci_conn_del(), hci_acl_create_conn_sync(), hci_le_create_conn_sync(), hci_cancel_connect_sync(), HCI_REQ_PEND, and hdev->sent_cmd. Correlate crash timestamps with Bluetooth adapter activity, pairing attempts, connection failures, proximity events, or user reports of Bluetooth device disconnects. Because this vulnerability primarily causes denial of service, indicators are more likely to be kernel crash artifacts and reboot events than persistent files, malware processes, or network-based IOCs.

• hci_abort_conn
• hci_rx_work
• hdev->sent_cmd
• HCI_REQ_PEND
• NULL pointer dereference
• general protection fault
• kernel NULL pointer dereference
• BUG: kernel NULL pointer dereference
• Oops:
• Bluetooth: hci_conn
• hci_conn_del
• hci_acl_create_conn_sync
• hci_le_create_conn_sync
• hci_cancel_connect_sync
• HCI_CONN_CREATE
• HCI_CONN_CREATE_CIS

What your security team should do

• Inventory Linux systems with Bluetooth hardware, Bluetooth services enabled, or loaded Bluetooth kernel modules.
• Prioritize kernel updates for Bluetooth-enabled laptops, workstations, embedded systems, kiosks, and operational devices where unexpected reboot or loss of Bluetooth connectivity would be disruptive.
• Disable Bluetooth on systems that do not have a business need for it, especially servers and fixed infrastructure devices.
• Monitor kernel logs for Bluetooth-related NULL pointer dereferences, general protection faults, oops events, and crashes involving hci_abort_conn or hci_rx_work.
• Ensure endpoint management, MDM, and configuration baselines enforce Bluetooth-off policies where Bluetooth is unnecessary.
• Track vendor advisories for exact fixed kernel package versions and confirm systems are rebooted into the patched kernel after update.
• Treat repeated Bluetooth-triggered kernel crashes as potentially suspicious even if public exploit maturity is currently listed as none.