CVE-2026-64406

What it actually does

This is a use-after-free flaw in the Linux kernel Bluetooth stack, specifically in bt_accept_dequeue() handling of accepted Bluetooth socket references. The vulnerable logic can drop a temporary reference before unlinking an accepted socket from the queue; if that was the final reference, later code can call sock_hold() on memory that has already been freed. In practical terms, this can corrupt kernel memory and may allow a low-privileged actor with access to the vulnerable Bluetooth code path to trigger a kernel crash or potentially achieve kernel-level code execution. The CVSS vector indicates adjacent-network attack surface, low attack complexity, low privileges required, no user interaction, and high confidentiality, integrity, and availability impact.

Why it matters to the business

Successful exploitation could crash Linux systems, disrupt Bluetooth-dependent workflows, or potentially allow an attacker to gain elevated control over affected hosts. Because this is in kernel code, impact can extend beyond the Bluetooth subsystem to full system compromise or denial of service. The issue is not currently listed in CISA KEV, has no known public exploit maturity in the supplied data, and has a low EPSS score, but kernel memory-safety bugs should still be prioritized on systems with Bluetooth enabled, especially workstations, kiosks, medical/industrial devices, and embedded Linux platforms exposed to nearby untrusted devices.

How an attack unfolds

An attacker positions themselves within Bluetooth range or otherwise gains access to exercise the Linux Bluetooth socket path. They interact with L2CAP/listening Bluetooth socket behavior in a way that causes accepted socket entries to be dequeued during cleanup. On a vulnerable kernel, the reference-counting order can free the socket object before a later sock_hold() operation uses it. This can result in a kernel use-after-free condition. Depending on heap state, kernel hardening, and exploit reliability, the outcome may be a system crash, memory corruption, information disclosure, privilege escalation, or arbitrary code execution in kernel context. There are no supplied indicators that this vulnerability is being exploited in the wild, but exploitation attempts would likely correlate with Bluetooth connection activity followed by kernel warnings, crashes, or KASAN use-after-free reports referencing bt_accept_dequeue(), bt_accept_unlink(), or sock_hold().

How to fix it

Apply the vendor-provided Linux kernel update that contains the Bluetooth bt_accept_dequeue() reference-handling fix. Because no affected product list or fixed package versions were supplied, track the advisory and patched kernel versions from the relevant Linux distribution, appliance vendor, or embedded platform maintainer. Where immediate patching is not possible, reduce exposure by disabling Bluetooth on systems that do not require it, disabling discoverability and pairing, restricting physical proximity to sensitive systems, limiting local interactive users, and monitoring for Bluetooth-related kernel crashes. For servers and production systems that do not need Bluetooth, consider disabling the Bluetooth service and preventing Bluetooth kernel modules from loading as a compensating control, subject to vendor support requirements.

How to confirm the fix worked

Confirm that systems are running a kernel version that includes the upstream or vendor backport for the bt_accept_dequeue() use-after-free fix. Validate through vendor advisory mapping, package changelogs, kernel build metadata, and reboot status after patching. On Linux, check the running kernel with uname -r and compare it to the vendor-fixed kernel version; also verify that the updated kernel is actually booted, not merely installed. If Bluetooth is intentionally disabled as a mitigation, confirm that Bluetooth services are stopped, Bluetooth adapters are unavailable or blocked, and relevant modules are not loaded. Review kernel logs after remediation for absence of KASAN, BUG, Oops, panic, or use-after-free messages referencing Bluetooth, L2CAP, bt_accept_dequeue(), bt_accept_unlink(), or sock_hold().

Typical attack path

1. Identify a Linux system with Bluetooth enabled and a kernel containing the vulnerable Bluetooth accept-queue logic.
2. Get within Bluetooth/adjacent-network range or otherwise reach the vulnerable Bluetooth stack path.
3. Trigger L2CAP or Bluetooth socket accept and cleanup behavior that exercises bt_accept_dequeue().
4. Manipulate timing and object lifetime so the socket reference is released before subsequent use.
5. Cause kernel memory use-after-free, leading to crash, memory corruption, or potential kernel-level execution depending on exploit reliability and mitigations.
6. Use resulting elevated privileges or denial-of-service condition to disrupt operations or continue post-exploitation activity.

How to detect it

There are no universally reliable network indicators for prior exploitation because this is a kernel memory-corruption issue in the Bluetooth stack and successful attempts may leave only crash or kernel telemetry. Review kernel logs, system journals, crash dumps, pstore/ramoops records, audit logs, EDR telemetry, and Bluetooth service logs for unexpected crashes or memory-safety reports. Focus searches on KASAN, BUG, Oops, panic, slab, refcount, and use-after-free messages mentioning bt_accept_dequeue(), bt_accept_unlink(), sock_hold(), L2CAP, or Bluetooth sockets. Correlate suspicious kernel events with nearby Bluetooth activity, unexpected pairing or connection attempts, hci events, service restarts, and unexplained reboots. If crash dumps are available, inspect stack traces for Bluetooth accept-queue functions and socket reference handling. Absence of these artifacts does not prove non-exploitation, especially on systems without kernel sanitizers, persistent logs, or crash capture enabled.

• BUG: KASAN: use-after-free in bt_accept_dequeue
• KASAN: use-after-free
• bt_accept_dequeue
• bt_accept_unlink
• sock_hold
• l2cap_sock_release
• l2cap_sock_cleanup_listen
• Bluetooth:
• kernel BUG at net/bluetooth
• Oops:
• general protection fault
• slab-use-after-free
• use-after-free in bt_accept_dequeue

What your security team should do

• Prioritize patching Linux endpoints, embedded devices, and appliances with Bluetooth enabled or reachable by untrusted nearby devices.
• Inventory systems with active Bluetooth adapters, L2CAP usage, or Bluetooth services and treat them as the highest-exposure population.
• For systems that do not require Bluetooth, disable Bluetooth services and hardware access as a near-term mitigation.
• Monitor kernel and system logs for crashes or memory-safety reports involving bt_accept_dequeue(), bt_accept_unlink(), sock_hold(), L2CAP, or Bluetooth socket cleanup.
• Ensure endpoint and fleet-management tooling verifies the running kernel version after reboot, not only the installed package version.
• Increase urgency if a public exploit appears, EPSS rises materially, the issue is added to KEV, or vendor advisories identify broadly deployed affected kernels.
• For high-assurance systems, consider enabling kernel hardening features and crash collection so attempted exploitation produces useful forensic artifacts.