CVE-2026-98108: Bluetooth: L2CAP: fix chan mode for LE_CONN_REQ + EXT_FLOWCTL pchan
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: fix chan mode for LECONNREQ + EXTFLOWCTL pchan
l2capnewconnection() sets default value of channel mode to match the parent channel. l2capleconnectreq() left this at the default, and created L2CAPMODEEXTFLOWCTL channels if listening pchan has that mode. This causes FLAGDEFERSETUP channels to reply to L2CAPLECONNREQ with L2CAPECREDCONNRSP, which is incorrect.
It can also result to stack OOB write (of l2capalloccid determined values) in l2capecredrspdefer(), as l2capleconnectreq() does not limit maximum number of deferred channels or check for duplicate ident.
Fix by setting chan->mode correctly in l2capleconnectreq().
Also check channel mode in l2capecredrspdefer(), and do WARNONONCE instead of OOB write to make it less brittle.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In the Linux kernel Bluetooth L2CAP implementation, set chan->mode correctly in l2cap_le_connect_req(); in l2cap_ecred_rsp_defer(), check the channel mode and use WARN_ON_ONCE to detect an unexpected mode.
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Linux kernel systems using Bluetooth L2CAP are relevant, specifically where an LE connection request is handled against a listening physical channel configured for extended flow-control mode with deferred setup behavior.
What conditions are needed to trigger the memory-safety issue?
The problematic path involves LE connection requests and an extended flow-control listening physical channel. Deferred channel handling can reach l2cap_ecred_rsp_defer() without limits on the number of deferred channels or checks for duplicate identifiers, leading to an out-of-bounds stack write.
How does the fix mitigate the issue?
The fix sets the new channel's mode correctly in l2cap_le_connect_req(). It also verifies channel mode in l2cap_ecred_rsp_defer() and uses WARN_ON_ONCE rather than allowing the out-of-bounds write.