CVE-2026-98107: Bluetooth: L2CAP: fix out-of-bounds write in l2cap_ecred_connect
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: fix out-of-bounds write in l2capecredconnect
l2capchanconnect() tries to ensure there are no more than L2CAPECREDCONNSCIDMAX pending ECRED channels, so they fit in the same L2CAPECREDCONNREQ that l2capecredconnect() constructs.
However, the check only counts deferred channels. If 6 L2CAP sockets are connected at the same time in order DDDDND (D=deferred, N=non-deferred), the last can bump the total to max+1. It results to one le16 written out of bounds of the scid array, and an invalid ECREDCONNREQ being sent.
Fix by leaving room for the non-deferred pending ECRED channels in the counting in l2capchanconnect(), so the limit can't be exceeded.
Move counting under same critical section where the channel is added. Although race conditions involving this appear unreachable, it's easier to see.
Also add WARNONONCE check in l2capecreddeferconnect() to make this less brittle.
Affected Software
Event History
Frequently Asked Questions
What conditions are needed to trigger the out-of-bounds write?
Six L2CAP sockets must be connected concurrently in the sequence deferred, deferred, deferred, deferred, non-deferred, deferred. This allows pending ECRED channels to exceed L2CAP_ECRED_CONN_SCID_MAX because the original check counted only deferred channels.
What is the observable effect when the limit is exceeded?
The kernel writes one __le16 value beyond the SCID array while constructing an ECRED connection request. It also sends an invalid ECRED_CONN_REQ.
What does the fix change?
The fix includes non-deferred pending ECRED channels when enforcing the connection limit, preventing the maximum from being exceeded. It also performs the counting in the same critical section that adds the channel and adds a WARN_ON_ONCE check in l2cap_ecred_defer_connect().