CVE-2026-64557

What it actually does

This is a Linux kernel use-after-free vulnerability in the Bluetooth L2CAP socket connection path. The vulnerable code can expose a newly created child socket on an accept queue, drop the parent socket lock, and then dereference the child socket after another task may already have accepted and freed it. If triggered successfully, this can lead to kernel memory corruption. Because the flaw is in kernel Bluetooth networking code, impact can include system crash, denial of service, information disclosure, or potentially arbitrary code execution in kernel context depending on exploit reliability and platform hardening.

Why it matters to the business

Systems with Bluetooth enabled may be exposed to attack from a nearby attacker within Bluetooth radio range, potentially allowing disruption or compromise without valid credentials or user interaction. The practical exposure is highest for laptops, workstations, kiosks, embedded Linux devices, industrial/medical devices, and mobile or edge systems where Bluetooth is enabled and L2CAP functionality is reachable. Although the vulnerability has a high severity score, it is not currently listed in CISA KEV, is not reported as used in ransomware, and has low current EPSS, so prioritization should focus first on Bluetooth-enabled systems and externally exposed operational devices where physical proximity attacks are realistic.

How an attack unfolds

An attacker positions a malicious Bluetooth-capable device within radio range of a vulnerable Linux system. The target must have Bluetooth enabled and reachable L2CAP handling. The attacker initiates crafted or repeated L2CAP connection activity intended to exercise the vulnerable new-connection callback path. During connection handling, the kernel places a child socket on an accept queue and releases the parent socket lock. If timing causes another execution context to accept and free that child socket before the callback uses it, the kernel dereferences freed memory. A successful exploit may corrupt kernel memory, crash the system, leak sensitive memory, or potentially gain code execution with kernel privileges. No public exploit maturity or known active exploitation was provided, so defenders should treat exploitation as plausible but not confirmed in the wild.

How to fix it

Apply a Linux kernel update from the relevant distribution or vendor that includes the Bluetooth L2CAP fix for l2cap_sock_new_connection_cb() and the revised child channel lifetime handling. Because no specific affected product list or fixed package versions were provided, rely on vendor advisories, distribution security trackers, and kernel changelogs for the exact patched kernel build. Where immediate patching is not possible, disable Bluetooth entirely, block automatic Bluetooth service startup, remove or blacklist Bluetooth kernel modules where operationally acceptable, and restrict physical access to systems with Bluetooth enabled. For servers and appliances that do not require Bluetooth, make Bluetooth disablement a permanent baseline control.

How to confirm the fix worked

Confirm remediation by verifying the running kernel is a vendor-patched build that includes the L2CAP new-connection lifetime fix; do not rely only on upstream version numbers because many Linux distributions backport security fixes. Check package manager security advisories, kernel changelogs, or source patches for references to the Bluetooth L2CAP use-after-free fix, l2cap_sock_new_connection_cb(), l2cap_new_connection(), or l2cap_chan_set_defaults(). Validate that patched systems have been rebooted into the updated kernel. For mitigations, confirm Bluetooth is disabled at runtime and across reboot, and verify Bluetooth kernel modules are not loaded where they are not required. Exposure testing should include checking whether Bluetooth adapters are present, powered, discoverable, pairable, or advertising services.

Typical attack path

1. Identify a Linux system with Bluetooth enabled and reachable within radio range.
2. Initiate Bluetooth discovery or connection attempts to determine whether L2CAP services are available.
3. Send crafted or high-frequency L2CAP connection attempts to trigger the vulnerable new-connection handling path.
4. Race the kernel socket accept/free lifecycle so the child socket is freed before it is dereferenced.
5. Leverage the resulting use-after-free for denial of service, memory disclosure, or possible kernel-level code execution.
6. If code execution is achieved, attempt persistence, credential access, lateral movement, or defense evasion from the compromised host.

How to detect it

There are no unique network indicators that reliably identify exploitation from the vulnerability details alone. Investigate signs of attempted or successful exploitation using kernel logs, systemd-journald, syslog, crash dumps, Bluetooth daemon logs, audit logs, EDR telemetry, and, where available, btmon/HCI packet captures. Look for kernel oops, panic, KASAN, KFENCE, slab, or general protection fault messages referencing Bluetooth L2CAP functions such as l2cap_sock_new_connection_cb(), l2cap_new_connection(), l2cap_sock_accept(), release_sock(), or l2cap_chan. Correlate crashes with nearby Bluetooth connection attempts, unknown Bluetooth MAC addresses, repeated pairing or connection failures, bursts of L2CAP connection requests, or unexpected Bluetooth adapter state changes. If a crash dump is available, inspect kernel call traces for L2CAP socket connection handling and use-after-free signatures. Because exploitation requires proximity, combine host telemetry with physical-location context where possible, such as recent presence of unknown Bluetooth devices near affected endpoints.

• BUG: KASAN: use-after-free
• KASAN: use-after-free in l2cap_sock_new_connection_cb
• KFENCE: use-after-free
• general protection fault
• kernel BUG at
• Oops:
• PANIC:
• l2cap_sock_new_connection_cb
• l2cap_new_connection
• l2cap_sock_accept
• l2cap_chan_set_defaults
• Bluetooth: L2CAP
• use-after-free in l2cap
• slab-use-after-free
• btmon
• bluetoothd

What your security team should do

• Inventory Linux endpoints, appliances, and embedded systems with Bluetooth hardware or Bluetooth kernel modules enabled.
• Prioritize patching for laptops, workstations, kiosks, medical/industrial devices, and edge systems where attackers could plausibly get within Bluetooth range.
• Disable Bluetooth on systems where it is not required, especially servers and fixed infrastructure.
• Monitor kernel, systemd-journald, syslog, audit, and Bluetooth daemon logs for crashes or anomalous L2CAP/Bluetooth activity until patching is complete.
• Ensure patched kernels are actually running by requiring reboot validation after kernel package updates.
• For high-risk locations, consider RF/physical security controls and alerting for unknown Bluetooth devices near sensitive systems.
• Track vendor advisories for exact fixed kernel package versions because no per-product fixed versions were supplied in the input.
• Treat kernel crashes involving Bluetooth, L2CAP, or use-after-free diagnostics as potential security events, not only reliability issues.