CVE-2026-98108: Bluetooth: L2CAP: fix chan mode for LE_CONN_REQ + EXT_FLOWCTL pchan
Bluetooth: L2CAP: fix chan mode for LECONNREQ + EXTFLOWCTL pchan
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.6.158.1-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.1.190-1Fixed in 6.12.113-1Fixed in 7.2.12-1Fixed in 7.2.13-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - Compensating control
In l2cap_le_connect_req(), set chan->mode correctly instead of leaving it at the default inherited from the parent channel.
- Compensating control
In l2cap_ecred_rsp_defer(), check the channel mode and use WARN_ON_ONCE instead of performing the out-of-bounds write.
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.