CVE-2026-63976

What it actually does

This vulnerability is in the Linux kernel Bluetooth L2CAP Enhanced Credit Based Flow Control reconfiguration response handling. After a successful ECRED reconfiguration, the kernel fails to clear the channel transaction identifier. Because L2CAP identifiers can be reused, a malicious Bluetooth peer that previously completed a valid reconfiguration can later replay or send a failure response using the stale identifier. The kernel may incorrectly associate that response with an already-established channel and tear it down with a connection reset. The practical impact is remote disruption of Bluetooth L2CAP channels from adjacent radio range. The published CVSS vector rates confidentiality, integrity, and availability impact as high, but the described bug most directly supports denial of service against Bluetooth communication channels rather than arbitrary code execution.

Why it matters to the business

Systems that rely on Linux Bluetooth connectivity may experience unexpected Bluetooth session resets, degraded device connectivity, or loss of service for Bluetooth-dependent workflows. This is most relevant for laptops, mobile/embedded Linux devices, kiosks, industrial handhelds, point-of-sale peripherals, medical or operational devices, and IoT products using Bluetooth L2CAP. Exploitation requires the attacker to be within Bluetooth radio range, which limits internet-scale exposure, but attacks may be practical in public, shared, or physically accessible environments. The issue is not currently listed in CISA KEV, has no known ransomware association, and has low EPSS at the time of publication, so urgency should be driven by Bluetooth exposure and operational reliance rather than broad active exploitation.

How an attack unfolds

An attacker positions a Bluetooth-capable device within range of a vulnerable Linux system with Bluetooth enabled. The attacker establishes or interacts with an L2CAP channel that supports ECRED reconfiguration and completes a legitimate reconfiguration exchange as the peer. Because the vulnerable kernel does not clear the channel identifier after the successful response, the channel retains a stale transaction identifier. The attacker then sends or replays a failure response using that stale identifier after the identifier value becomes relevant again. The kernel incorrectly matches the failure response to the established channel and deletes the channel with a connection reset, disrupting the Bluetooth session. Repeating the sequence can cause recurring Bluetooth service instability for affected channels or devices.

How to fix it

Upgrade the Linux kernel to a version that includes the fix for the Bluetooth L2CAP ECRED reconfiguration response handling issue. The fix clears chan->ident after successful ECRED reconfiguration and hardens the failure path with safer channel reference handling. If vendor-specific fixed package versions are not yet available, apply the relevant upstream stable kernel update when released by the operating system or device vendor. As interim mitigations, disable Bluetooth where not required, restrict Bluetooth use on sensitive systems, reduce discoverability and pairing exposure, remove untrusted pairings, and limit physical access to areas where Bluetooth-enabled systems operate. For embedded or appliance environments, obtain firmware updates from the device vendor and plan maintenance windows for kernel or firmware replacement.

How to confirm the fix worked

Confirm the running kernel or vendor firmware includes the upstream Bluetooth L2CAP fix for l2cap_ecred_reconf_rsp(). Validate package status using the operating system vendor advisory, kernel changelog, or source patch history rather than relying only on version strings, because fixes may be backported. On Linux systems, verify the active kernel with uname -r and compare it against the vendor’s fixed kernel package. Confirm Bluetooth is disabled on systems where it is not needed using rfkill, bluetoothctl, systemctl status bluetooth, or equivalent platform controls. Where practical, perform controlled Bluetooth regression testing to verify ECRED reconfiguration no longer leaves stale channel identifiers and that malformed or replayed failure responses do not reset established channels.

Typical attack path

1. Attacker comes within Bluetooth radio range of a vulnerable Linux device.
2. Attacker identifies that Bluetooth is enabled and that L2CAP/LE credit-based channels can be reached.
3. Attacker establishes or participates in an L2CAP ECRED-capable connection with the target.
4. Attacker completes an ECRED reconfiguration transaction successfully.
5. The vulnerable kernel leaves the channel identifier uncleared after the successful transaction.
6. Attacker sends or replays a crafted failure response using the stale identifier.
7. The kernel incorrectly matches the response to the established channel and resets/deletes it.
8. Bluetooth-dependent applications or peripherals experience dropped connections or service disruption.

How to detect it

To assess possible prior exploitation, review kernel logs, system journals, Bluetooth daemon logs, and endpoint telemetry for unusual Bluetooth disconnects or repeated L2CAP channel resets, especially clustered by time and physical location. Useful sources include journald, dmesg, /var/log/kern.log, /var/log/syslog, bluetoothd logs, audit/EDR telemetry showing Bluetooth service restarts, and application logs from Bluetooth-dependent services. Look for recurring connection resets, unexplained Bluetooth peripheral drops, L2CAP errors, ECRED-related failures, or bursts of connect/reconfigure/disconnect activity without normal user interaction. Because the attack is over Bluetooth and may not leave network-layer evidence, correlation with physical proximity, device movement, help desk reports, and Bluetooth adapter activity is important. If Bluetooth packet captures are available, review for ECRED reconfiguration followed by replayed or unexpected failure responses using repeated identifiers. There are no public reports of known exploitation, named threat actors, or ransomware use based on the provided data.

• l2cap_ecred_reconf_rsp
• l2cap_chan_del
• ECONNRESET
• L2CAP
• ECRED
• Bluetooth:
• bluetoothd
• Connection reset by peer
• /var/log/kern.log
• /var/log/syslog
• dmesg
• journalctl -k

What your security team should do

• Inventory Linux systems and embedded devices with Bluetooth enabled, prioritizing devices in public, shared, high-traffic, or physically accessible locations.
• Apply vendor kernel or firmware updates that include the Bluetooth L2CAP ECRED fix as soon as they are available, prioritizing devices that depend on Bluetooth for operations.
• Disable Bluetooth on servers, workstations, appliances, and embedded systems where it is not operationally required.
• Review and remove unnecessary or unknown Bluetooth pairings, and enforce local policy limiting Bluetooth discoverability and pairing.
• Monitor for repeated Bluetooth disconnects, L2CAP channel resets, kernel Bluetooth errors, or user reports of Bluetooth instability in physically exposed locations.
• For high-risk environments, consider physical security controls and Bluetooth radio monitoring to detect suspicious nearby devices attempting repeated connections.
• Track vendor advisories for exact fixed kernel package versions and backported fixes, since affected product and fixed-version metadata may vary by distribution.