CVE-2026-63975: Bluetooth: L2CAP: Fix possible crash on l2cap_ecred_conn_rsp
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix possible crash on l2capecredconnrsp
If dcid is received for an already-assigned destination CID the spec requires that both channels to be discarded, but calling l2capchandel may invalidate the tmp cursor created by listforeachentrysafe and in fact it is the wrong procedure as the chan->dcid may be assigned previously it really needs to be disconnected.
Calling l2capchanclone directly may still lead to l2capchandel so instead schedule l2capchantimeout with delay 0 to close the channel asynchronously.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In the L2CAP ecredit connection response handling, schedule l2cap_chan_timeout with delay 0 to close the channel instead of directly calling l2cap_chan_del, because the channel's destination CID may already be assigned and direct deletion can invalidate the list_for_each_entry_safe cursor.
Event History
Frequently Asked Questions
What level of access does an attacker need?
The CVSS vector indicates adjacent-network access is required. No privileges or user interaction are required according to the supplied vector.
Which systems are exposed?
Systems running the Linux kernel with Bluetooth L2CAP handling are the relevant exposure area. The issue is specifically triggered while processing an Enhanced Credit Based connection response (ECRED).
What condition triggers the crash?
The vulnerable path involves receiving a destination CID that is already assigned. This can cause unsafe channel deletion during response processing, resulting in a possible use-after-free crash.
How can I determine whether the fix is present?
Check whether the kernel source or vendor kernel changelog includes one of the referenced stable commits: 3c8eaa91eb433c450426539290be4ffe282e9f00, ecfed1e0d8efecad6737a0d83e21d2fd021d8c48, or e6833e737a51db1e5ea0401322acf5e22abd8be6. The corrected behavior schedules asynchronous channel closure rather than deleting the channel directly in this path.