Monitor vulnerabilities like this one.
Sign up free to get alerted when software you use is affected.
8.8
CVE-2026-23395: Linux Bluetooth: L2CAP accepts too many connection requests
CVE-2026-23395
Summary
This vulnerability affects Linux's Bluetooth connection handling. A flaw allows too many requests to be processed at once, which can lead to an overflow error. To fix this, the Linux kernel developers have updated the code to reject repeated requests with the same identifier, as per the Bluetooth standard.
Original title
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix accepting multiple L2CAP_ECRED_CONN_REQ
Currently the code attempts to accept requests regardless of the
...
Original description
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix accepting multiple L2CAP_ECRED_CONN_REQ
Currently the code attempts to accept requests regardless of the
command identifier which may cause multiple requests to be marked
as pending (FLAG_DEFER_SETUP) which can cause more than
L2CAP_ECRED_MAX_CID(5) to be allocated in l2cap_ecred_rsp_defer
causing an overflow.
The spec is quite clear that the same identifier shall not be used on
subsequent requests:
'Within each signaling channel a different Identifier shall be used
for each successive request or indication.'
https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core-62/out/en/host/logical-link-control-and-adaptation-protocol-specification.html#UUID-32a25a06-4aa4-c6c7-77c5-dcfe3682355d
So this attempts to check if there are any channels pending with the
same identifier and rejects if any are found.
Bluetooth: L2CAP: Fix accepting multiple L2CAP_ECRED_CONN_REQ
Currently the code attempts to accept requests regardless of the
command identifier which may cause multiple requests to be marked
as pending (FLAG_DEFER_SETUP) which can cause more than
L2CAP_ECRED_MAX_CID(5) to be allocated in l2cap_ecred_rsp_defer
causing an overflow.
The spec is quite clear that the same identifier shall not be used on
subsequent requests:
'Within each signaling channel a different Identifier shall be used
for each successive request or indication.'
https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core-62/out/en/host/logical-link-control-and-adaptation-protocol-specification.html#UUID-32a25a06-4aa4-c6c7-77c5-dcfe3682355d
So this attempts to check if there are any channels pending with the
same identifier and rejects if any are found.
- https://git.kernel.org/stable/c/2124d82fd25e1671bb3ceb37998af5aae5903e06
- https://git.kernel.org/stable/c/5b3e2052334f2ff6d5200e952f4aa66994d09899
- https://git.kernel.org/stable/c/6b949a6b33cbdf621d9fc6f0c48ac00915dbf514
- https://git.kernel.org/stable/c/8d0d94f8ba5b3a0beec3b0da558b9bea48018117
- https://git.kernel.org/stable/c/e72ee455297b794b852e5cea8d2d7bb17312172a
- https://git.kernel.org/stable/c/fb4a3a26483f3ea2cd21c7a2f7c45d5670600465
Published: 25 Mar 2026 · Updated: 20 Jul 2026 · First seen: 25 Mar 2026