CVE-2026-63975

What it actually does

This vulnerability is a Linux kernel Bluetooth L2CAP Enhanced Credit Based Flow Control issue in handling l2cap_ecred_conn_rsp responses. A nearby attacker within Bluetooth radio range can send a crafted L2CAP response containing a destination channel identifier that collides with an already assigned destination CID. The vulnerable code may delete or invalidate channel-list state while iterating over it, leading to unsafe kernel object handling and a potential kernel crash. The practical impact is primarily denial of service against systems with vulnerable kernel builds and enabled Bluetooth support; depending on kernel configuration and runtime state, the crash may result in a full system panic, service interruption, or forced reboot.

Why it matters to the business

Systems that rely on Bluetooth while running affected Linux kernel versions may be disrupted by an attacker in close physical proximity. The most likely consequence is operational downtime from kernel crashes or reboots on laptops, workstations, embedded Linux devices, kiosks, industrial tablets, medical devices, point-of-sale systems, or IoT/edge systems using Bluetooth. The issue is not currently listed in CISA KEV, has no known ransomware association, and has low EPSS at the time of assessment, but the CVSS score is high and the attack requires no authentication or user interaction once an attacker is within Bluetooth range.

How an attack unfolds

An attacker positions a Bluetooth-capable device within radio range of a vulnerable Linux system whose Bluetooth stack is enabled and reachable. The attacker initiates or manipulates an L2CAP Enhanced Credit Based connection flow and sends a malformed or specification-violating connection response where the destination CID is already assigned. The vulnerable kernel path processes the duplicate destination CID and attempts to discard or delete channel state in a way that can invalidate iteration state or otherwise mishandle channel lifetime. This can trigger a kernel fault, panic, Bluetooth subsystem failure, or system reboot. Exploitation is local-adjacent rather than internet-routable, so successful attacks are most plausible in shared physical spaces such as offices, public venues, manufacturing floors, hospitals, retail locations, or anywhere attackers can get near Bluetooth-enabled Linux devices.

How to fix it

Apply Linux kernel updates from the relevant operating system, appliance, or device vendor that include the upstream Bluetooth L2CAP fix for l2cap_ecred_conn_rsp duplicate destination CID handling. Because no product-specific fixed versions were provided, use vendor advisories and kernel changelogs to confirm inclusion of the patch titled along the lines of "Bluetooth: L2CAP: Fix possible crash on l2cap_ecred_conn_rsp." Where immediate patching is not possible, reduce exposure by disabling Bluetooth on systems that do not require it, blocking Bluetooth service startup, removing or blacklisting Bluetooth kernel modules where operationally safe, and limiting use of vulnerable devices in untrusted physical areas. For embedded or managed fleets, coordinate firmware, distribution kernel, and vendor appliance updates rather than assuming upstream kernel version alone reflects patch status.

How to confirm the fix worked

Confirm the running kernel package or firmware build includes the vendor fix for the Linux Bluetooth L2CAP l2cap_ecred_conn_rsp crash. Validate both the installed package version and the actively running kernel after reboot, since Linux kernel updates often require a restart. Check that Bluetooth is disabled where mitigation is intended, including system service state, kernel module load state, and hardware radio state. On representative patched systems, review vendor regression notes or perform controlled Bluetooth interoperability testing to ensure normal pairing and L2CAP-dependent functionality continues to work. Exposure is present only where a vulnerable kernel build is running and Bluetooth functionality is enabled or loadable.

Typical attack path

1. Identify or approach a Linux-based target with Bluetooth enabled and discoverable or otherwise reachable over Bluetooth.
2. Use a Bluetooth-capable attack device to interact with the target's L2CAP stack.
3. Initiate an L2CAP Enhanced Credit Based connection sequence or reach the vulnerable response-handling code path.
4. Send a crafted l2cap_ecred_conn_rsp message containing a destination CID that is already assigned.
5. Trigger incorrect channel cleanup or disconnect handling in the kernel Bluetooth L2CAP implementation.
6. Cause a Bluetooth subsystem failure, kernel oops, kernel panic, reboot, or availability disruption.

How to detect it

Review Linux kernel logs, persistent journal data, crash dumps, and endpoint telemetry for Bluetooth/L2CAP errors immediately preceding kernel oops, panic, reboot, or unexpected service interruption. Useful sources include dmesg output, systemd journal entries for the kernel, /var/log/kern.log, /var/log/messages, /var/log/syslog, pstore records, kdump/vmcore artifacts, and Bluetooth daemon logs. Look for call traces referencing Bluetooth L2CAP functions, especially l2cap_ecred_conn_rsp, l2cap_chan_del, l2cap_chan_timeout, l2cap_chan_clone, or related channel cleanup paths. Because exploitation occurs over Bluetooth radio and may not leave network perimeter logs, correlate system crashes with physical proximity events, Bluetooth adapter activity, btmon captures where available, and repeated Bluetooth connection attempts from unknown device addresses. Absence of logs does not rule out exploitation if the system panicked before logs were flushed.

• l2cap_ecred_conn_rsp
• Bluetooth: L2CAP
• l2cap_chan_del
• l2cap_chan_timeout
• l2cap_chan_clone
• kernel BUG
• kernel panic
• Oops:
• BUG: kernel NULL pointer dereference
• general protection fault
• Unable to handle kernel paging request
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• /sys/fs/pstore
• /var/crash
• bluetoothd
• btmon

What your security team should do

• Inventory Linux systems, embedded devices, appliances, and endpoints with Bluetooth enabled or Bluetooth kernel modules loaded.
• Prioritize patching devices in physically accessible or public/shared locations, and systems where unexpected reboot or outage would have high operational impact.
• Deploy vendor kernel or firmware updates that include the L2CAP ecred connection response fix, then reboot into the patched kernel.
• Disable Bluetooth on servers, workstations, kiosks, and embedded devices that do not have a business requirement for it.
• For devices that cannot be patched promptly, use physical controls and configuration management to limit Bluetooth exposure in untrusted spaces.
• Monitor for unexplained kernel oops, panic, reboot, or Bluetooth subsystem errors on Linux systems with Bluetooth enabled.
• Track vendor advisories even though the vulnerability is not currently in CISA KEV and has low EPSS, because adjacent-network Bluetooth vulnerabilities can be exploited without credentials once an attacker is nearby.