CVE-2026-63975: Linux kernel · Bluetooth: L2CAP: Fix possible crash on l2cap_ecred_conn_rsp
Source GCVE Database
Not known to be exploited · CVSS 8.8 High · fixed in ecfed1e0d8efecad6737a0d83e21d2fd021d8c48 : patch Linux kernel soon.
Data as of 26 Oct 2026, 17:16 UTC
- EPSS
- 0.2% chance of exploitation in 30 days – higher than 19% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in ecfed1e0d8efecad6737a0d83e21d2fd021d8c48, e6833e737a51db1e5ea0401322acf5e22abd8be6, d153b8898c0051eb8b6a083b35cbe304a5886bd5 +5
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HExploitation evidence
Disclosed: evidence found.
CVE published 19 Jul 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
Upgrade to a fixed release listed under Affected software.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
AI-suggested
A fix has been implemented in the Linux kernel to address this issue by modifying the channel closure method. Users should apply the official Linux kernel updates that include this patch once available.
Description
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix possible crash on l2cap_ecred_conn_rsp If dcid is received for an already-assigned destination CID the spec requires that both channels to be discarded, but calling l2cap_chan_del may invalidate the tmp cursor created by list_for_each_entry_safe and in fact it is the wrong procedure as the chan->dcid may be assigned previously it really needs to be disconnected. Calling l2cap_chan_clone directly may still lead to l2cap_chan_del so instead schedule l2cap_chan_timeout with delay 0 to close the channel asynchronously.
References
- nvd.nist.gov/vuln/detail/CVE-2026-63975 (opens in a new tab)
- git.kernel.org/stable/c/291eec1041c918c460dc9702e44edd17794b4a4b (opens in a new tab)
- git.kernel.org/stable/c/3c8eaa91eb433c450426539290be4ffe282e9f00 (opens in a new tab)
- git.kernel.org/stable/c/41c2713b204e6cb6a94587bc6bf6935107df5479 (opens in a new tab)
- git.kernel.org/stable/c/41e29548b5e8b5e5fcf708786b3bea67cab107fa (opens in a new tab)
- git.kernel.org/stable/c/6319b38fe69f56ed95680ade485b957a53fff642 (opens in a new tab)
- git.kernel.org/stable/c/d153b8898c0051eb8b6a083b35cbe304a5886bd5 (opens in a new tab)
- git.kernel.org/stable/c/e6833e737a51db1e5ea0401322acf5e22abd8be6 (opens in a new tab)
- git.kernel.org/stable/c/ecfed1e0d8efecad6737a0d83e21d2fd021d8c48 (opens in a new tab)