CVE-2026-64433

What it actually does

This is a Linux kernel use-after-free in the Bluetooth Management (MGMT) path. The vulnerable code looks up an hci_conn_params object for a Bluetooth LE device and later reads params->flags without holding the required hci_dev_lock. A concurrent MGMT remove-device operation can delete and free that same connection-parameter object before it is read by add_device_complete(), causing the kernel to dereference freed slab memory from the hci_cmd_sync_work worker. The most likely technical outcome is a kernel crash or panic, especially on systems with memory debugging enabled, but kernel use-after-free conditions can sometimes be shaped into broader memory corruption, information disclosure, or privilege-escalation primitives depending on allocator behavior, timing, hardening, and attacker control of adjacent allocations.

Why it matters to the business

Systems with enabled Bluetooth support may be exposed to local denial-of-service risk if an attacker or untrusted workload can access the Bluetooth management interface. Successful exploitation could crash affected Linux hosts, interrupt endpoint, workstation, kiosk, IoT, embedded, or server operations that include Bluetooth-capable kernels, and require reboot or recovery. There is currently no CISA KEV listing, no ransomware association, low EPSS score, and no public exploit maturity reported, so broad active exploitation is not indicated; however, kernel bugs still deserve timely remediation because they affect system stability and may become more serious if exploit techniques emerge.

How an attack unfolds

An attacker needs the ability to issue Bluetooth MGMT commands to the local kernel, typically through the Linux Bluetooth HCI management socket and commonly requiring elevated local privileges or granted network/Bluetooth administration capabilities. The attacker repeatedly adds a Bluetooth LE device entry so that hci_conn_params is allocated, then races the asynchronous add-device completion worker against a remove-device operation. If remove_device() frees the connection-parameter object after add_device_complete() has looked it up but before it reads params->flags, the worker dereferences freed memory. In a straightforward exploitation scenario this produces a KASAN report, kernel oops, panic, or service disruption. More advanced exploitation would attempt to win the race reliably and reclaim the freed slab object with attacker-influenced data before the read, but no public weaponized exploitation is indicated by the provided intelligence.

How to fix it

Update the Linux kernel to a version that includes the Bluetooth MGMT locking fix for add_device_complete(), which holds hci_dev_lock across hci_conn_params_lookup(), the params->flags read, and the associated event emission. Because no product-specific fixed versions were provided, use the security update stream for the affected distribution, appliance, embedded build, or kernel vendor and verify that the patch for this issue is included. If immediate patching is not possible, reduce exposure by disabling Bluetooth where it is not required, unloading or blacklisting Bluetooth-related kernel modules, disabling Bluetooth services, and preventing untrusted users or containers from receiving capabilities such as CAP_NET_ADMIN that may allow access to Bluetooth management sockets. On containerized or multi-tenant Linux systems, avoid passing through Bluetooth devices or broad network administration capabilities to untrusted workloads.

How to confirm the fix worked

Confirm the running kernel includes the upstream or vendor backport that changes the Bluetooth MGMT add_device_complete() locking behavior. Validate by checking the installed kernel package changelog, vendor advisory, or source tree for the fix in net/bluetooth/mgmt.c around add_device_complete(). Ensure the active booted kernel is the patched kernel, not merely installed on disk. Where feasible, confirm Bluetooth is disabled on systems that do not require it by checking loaded modules, active Bluetooth services, and available HCI devices. For exposure validation, verify whether local users or workloads can open Bluetooth HCI management/control sockets or hold capabilities that would permit MGMT add/remove-device commands.

Typical attack path

1. Gain local execution on a Linux system with Bluetooth kernel support enabled.
2. Obtain permission to open and send commands to the Bluetooth HCI MGMT/control interface, such as through elevated privileges or a granted administration capability.
3. Send MGMT add-device operations that allocate Bluetooth LE connection-parameter state.
4. Concurrently send MGMT remove-device operations that free the same hci_conn_params object while asynchronous add-device completion is still pending.
5. Win the race so add_device_complete() reads params->flags after the object has been freed.
6. Cause a kernel memory-safety fault, oops, panic, or potentially attempt further heap manipulation if pursuing a more advanced kernel exploitation path.

How to detect it

Detection is primarily forensic because this vulnerability does not produce a unique network signature and exploitation occurs through local kernel Bluetooth management operations. Review kernel logs from journalctl, dmesg, /var/log/kern.log, /var/log/messages, crash dumps, pstore, and kdump/vmcore artifacts for use-after-free, KASAN, BUG, oops, panic, or slab corruption messages referencing Bluetooth MGMT code. High-value strings include add_device_complete, hci_conn_params, hci_conn_params_free, hci_conn_params_lookup, hci_cmd_sync_work, MGMT_OP_REMOVE_DEVICE, add_device, remove_device, and net/bluetooth/mgmt.c. If auditd, eBPF, or endpoint telemetry is available, look for processes opening AF_BLUETOOTH/HCI sockets and issuing frequent add/remove Bluetooth management operations shortly before a crash. In containerized environments, correlate crash timing with containers or services that had CAP_NET_ADMIN, host networking, or Bluetooth device passthrough. Absence of these artifacts does not prove non-exploitation, especially if the system did not retain kernel logs across reboot.

• BUG: KASAN: slab-use-after-free in add_device_complete
• slab-use-after-free in add_device_complete
• add_device_complete+
• net/bluetooth/mgmt.c:7671
• hci_cmd_sync_work
• Workqueue: hci0 hci_cmd_sync_work
• hci_conn_params_lookup
• hci_conn_params_free
• hci_conn_params_add
• MGMT_OP_REMOVE_DEVICE
• remove_device()
• add_device+
• Bluetooth: MGMT
• Read of size 1
• params->flags
• AF_BLUETOOTH
• HCI_CHANNEL_CONTROL

What your security team should do

• Prioritize patching Bluetooth-enabled Linux systems, especially endpoints, embedded devices, kiosks, and hosts where local users or workloads may have elevated capabilities.
• Inventory systems with Bluetooth hardware, loaded Bluetooth kernel modules, active bluetoothd service, or exposed HCI devices.
• Disable Bluetooth support on servers and production systems that do not require it.
• Review container, sandbox, and service configurations to remove unnecessary CAP_NET_ADMIN, host networking, device passthrough, and Bluetooth socket access.
• Monitor kernel logs for KASAN, use-after-free, oops, panic, or BUG messages referencing add_device_complete, hci_conn_params, hci_cmd_sync_work, or net/bluetooth/mgmt.c.
• Treat unexplained Bluetooth-related kernel crashes as potentially security-relevant and preserve kernel logs, crash dumps, and audit telemetry for investigation.
• Track vendor kernel advisories because fixed version names will vary by distribution and backport stream.