CVE-2026-98108 PUBLISHED

Bluetooth: L2CAP: fix chan mode for LE_CONN_REQ + EXT_FLOWCTL pchan

Assigner: Linux
Reserved: 25.09.2026 Published: 25.09.2026 Updated: 25.09.2026

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: L2CAP: fix chan mode for LE_CONN_REQ + EXT_FLOWCTL pchan

l2cap_new_connection() sets default value of channel mode to match the parent channel. l2cap_le_connect_req() left this at the default, and created L2CAP_MODE_EXT_FLOWCTL channels if listening pchan has that mode. This causes FLAG_DEFER_SETUP channels to reply to L2CAP_LE_CONN_REQ with L2CAP_ECRED_CONN_RSP, which is incorrect.

It can also result to stack OOB write (of l2cap_alloc_cid determined values) in l2cap_ecred_rsp_defer(), as l2cap_le_connect_req() does not limit maximum number of deferred channels or check for duplicate ident.

Fix by setting chan->mode correctly in l2cap_le_connect_req().

Also check channel mode in l2cap_ecred_rsp_defer(), and do WARN_ON_ONCE instead of OOB write to make it less brittle.

Metrics

CVSS Vector: CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 7.5

AV:A - The malformed input is a series of L2CAP_LE_CONN_REQ signalling commands, all using the same ident, sent over a BLE link to l2cap_le_connect_req(). The attacker must be within Bluetooth radio range, so the vector is Adjacent. AC:H - The OOB write only happens if the target runs an LE listener in BT_MODE_EXT_FLOWCTL with DEFER_SETUP, whose children inherit EXT_FLOWCTL through l2cap_new_connection(). The attacker cannot create that listener. Once it exists, the attacker controls how many LE_CONN_REQs share one ident, and the service's own recvmsg() triggers the write. PR:N - l2cap_le_connect_req() only checks the listener's sec_level through smp_sufficient_security(). An LE listener defaults to BT_SECURITY_LOW, so an unpaired peer can open the channels, and Just Works pairing is available otherwise. UI:N - No human action is needed. The listening service's normal accept/recvmsg on a deferred child calls l2cap_sock_recvmsg(), which then calls __l2cap_ecred_conn_rsp_defer(). S:U - The memory corruption stays within the kernel's own security authority. No VM or hardware isolation boundary is crossed. C:H - l2cap_ecred_rsp_defer() writes CIDs past the 5-entry scid[] into the adjacent 'count' field, which then steers later writes to attacker-influenced offsets on the kernel stack. Corruption of this kind can be leveraged for disclosure. I:H - This is an out-of-bounds write on the kernel stack in __l2cap_ecred_conn_rsp_defer(). The written values are l2cap_alloc_cid() CIDs whose count and order the attacker influences, and the write can reach the saved frame state. A:H - Stack corruption in __l2cap_ecred_conn_rsp_defer() causes a stack-protector panic or an oops, crashing the kernel, and the peer can repeat it.

Product Status

Vendor Linux
Product Linux
Versions Default: unaffected
  • affected from 15f02b91056253e8cdc592888f431da0731337b8 to 1074bcc57f741223f9fa82ce6afe5c3d783e4d10 (excl.)
  • affected from 15f02b91056253e8cdc592888f431da0731337b8 to 5d5a625cbc854d4c4f68e4b16fcf6e682d9a9ed1 (excl.)
  • affected from 15f02b91056253e8cdc592888f431da0731337b8 to 6cb79e6499228cfdbd4b3301371ce74d01cd2f80 (excl.)
  • affected from 15f02b91056253e8cdc592888f431da0731337b8 to 4ef05db5b08b176a551b4a6287372045998806b0 (excl.)
Vendor Linux
Product Linux
Versions Default: affected
  • Version 5.7 is affected
  • unaffected from 0 to 5.7 (excl.)
  • unaffected from 6.12.111 to 6.12.* (incl.)
  • unaffected from 6.18.53 to 6.18.* (incl.)
  • unaffected from 7.2.7 to 7.2.* (incl.)
  • unaffected from 7.3-rc2 to * (incl.)

References