CVE-2026-64434

What it actually does

This is a Linux kernel Bluetooth L2CAP use-after-free condition in the asynchronous channel timeout path. The timer worker l2cap_chan_timeout() can access chan->conn after the underlying l2cap_conn object has been freed during connection teardown, causing the worker to operate on freed kernel memory when it attempts to lock conn->lock. Because the flaw occurs in kernel space and the CVSS vector indicates adjacent-network exploitation with no authentication or user interaction, a Bluetooth-range attacker may be able to trigger memory corruption that can lead to denial of service and, depending on exploitability on a given kernel build and hardening configuration, possible kernel-level code execution or privilege escalation.

Why it matters to the business

Systems with enabled Bluetooth support may be exposed to attacks from nearby adversaries without requiring credentials or user interaction. Successful exploitation could crash affected hosts, disrupt endpoint availability, or potentially allow deeper compromise of the operating system. The low current EPSS score and lack of known public exploit maturity reduce immediate internet-scale risk, but the high CVSS score means organizations with Bluetooth-enabled laptops, workstations, kiosks, embedded Linux devices, or industrial/medical/retail endpoints should treat this as a priority kernel maintenance issue.

How an attack unfolds

An attacker within Bluetooth radio range initiates or manipulates an L2CAP connection to an affected Linux host. The attacker then causes a timing-sensitive sequence where an L2CAP channel timeout worker is scheduled while the associated Bluetooth connection is being torn down. In vulnerable kernels, the timeout handler can dereference the stale chan->conn pointer after the l2cap_conn object has already been freed. This can corrupt kernel memory or trigger a kernel crash. More advanced exploitation would require shaping heap layout and timing the connection teardown to turn the use-after-free into controlled memory reuse, which is generally platform- and kernel-configuration-dependent.

How to fix it

Apply a vendor-supplied Linux kernel update that includes the Bluetooth L2CAP reference-counting fix for this issue. Where immediate patching is not possible, reduce exposure by disabling Bluetooth on systems that do not require it, blocking automatic Bluetooth startup, disabling pairing/discoverability, and restricting physical proximity to sensitive systems. Practical mitigations include using rfkill to block Bluetooth, disabling the bluetooth service, removing or blacklisting Bluetooth kernel modules where operationally acceptable, and enforcing endpoint configuration policies that keep Bluetooth off by default. Because no exact fixed package versions were provided, use the affected distribution or device vendor advisory as the authoritative source for the corrected kernel version.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel version matches a vendor release that contains the L2CAP channel timeout reference fix. Reboot after kernel installation and confirm the patched kernel is active, not merely installed. Validate exposure reduction by checking whether Bluetooth adapters are blocked or absent where Bluetooth is not required. On Linux systems, review `uname -a`, distribution package metadata for the installed kernel, `rfkill list`, `systemctl status bluetooth`, and loaded modules such as `bluetooth`, `btusb`, `hci_uart`, and related HCI drivers. If source validation is available, confirm the kernel contains the change that holds a reference to l2cap_conn when a channel is added and releases it in the channel destructor.

Typical attack path

1. Identify a nearby Linux device with Bluetooth enabled and discoverable or otherwise reachable over Bluetooth.
2. Establish or provoke Bluetooth L2CAP activity with the target device.
3. Manipulate connection state so that an L2CAP channel timeout is pending while the underlying Bluetooth connection is closed or torn down.
4. Trigger the asynchronous l2cap_chan_timeout() worker to access the freed l2cap_conn object.
5. Cause a kernel crash or attempt to exploit the resulting kernel memory corruption for higher-impact compromise.

How to detect it

Look for evidence of Bluetooth-triggered kernel instability or memory corruption. Useful sources include kernel logs, system journal entries, crash dumps, pstore/ramoops, kdump vmcores, EDR kernel panic telemetry, and Bluetooth daemon logs. Search for KASAN use-after-free reports involving l2cap_chan_timeout, conn->lock, l2cap_conn, l2cap_core.c, hci disconnect paths, or workqueue crashes. Also review bursts of Bluetooth connect/disconnect activity preceding a crash, unexpected HCI device teardown, L2CAP timeout messages, or repeated Bluetooth adapter resets. Because exploitation is proximity-based, correlate suspicious events with physical access windows, Bluetooth adapter activity, and endpoint location where possible. Absence of these artifacts does not prove non-exploitation, especially on production kernels without KASAN or persistent crash logging enabled.

• BUG: KASAN: slab-use-after-free
• slab-use-after-free in mutex_lock
• l2cap_chan_timeout
• net/bluetooth/l2cap_core.c:422
• Workqueue: events l2cap_chan_timeout
• chan->conn
• conn->lock
• l2cap_conn_add
• l2cap_connect_cfm
• hci_disconn_cfm
• hci_conn_hash_flush
• hci_dev_close_sync
• hci_unregister_dev
• vhci_release
• Bluetooth: L2CAP
• kernel BUG at net/bluetooth/l2cap_core.c
• Oops:
• Kernel panic
• general protection fault
• KASAN: use-after-free

What your security team should do

• Prioritize patching Bluetooth-enabled Linux endpoints, embedded systems, kiosks, and workstations that may be physically accessible to attackers.
• Disable Bluetooth wherever it is not required, especially on servers, privileged administrator workstations, and fixed-function appliances.
• Inventory Linux assets with active Bluetooth adapters using endpoint management, EDR, or configuration management tooling.
• Monitor for kernel crash, KASAN, oops, panic, and Bluetooth L2CAP anomalies until patching is complete.
• Require a reboot after kernel updates and verify the patched kernel is the running kernel.
• For high-security environments, enforce policy-based Bluetooth disablement and restrict pairing/discoverability even after patching.
• Track vendor advisories for exact fixed kernel package versions because fixed versions were not supplied in the input.