CVE-2026-99239 Condición de carrera en __l2cap_chan_add de Bluetooth L2CAP

Afectados

• Linux

  desde 8f90405a4a6f1f1880dc07996b47bf57c712bd8a hasta antes de 85cc289eb08afa975375f838187369e68b429ee0desde 32d783cafb46ff3ca58e6f9fd62c9c5f35eaf26b hasta antes de 820579652b24ce277e0097cd65b42bd9b7b8bf07desde 8922c7940bae9ce4b1736dddb6362370793835c2 hasta antes de e618d928ec7f88cbeadfa3542adcac40f474e629desde 91047a4396a8b1857a6f712a90cf33ec0012b189 hasta antes de fabaff1c59ff2cc89cb7e5bd0186a5e15f0c73b2desde 0b0e2bf39cf99e458d991b9df253727e036a7d7d hasta antes de 52fe88e4ef87311eee32b45c65603e7c69e75e7ddesde d3b739db5dc6f688a60d56da872fabaf65246032 hasta antes de 10c705dd706aa93164ba41f2566f15206d6c178edesde b66774b48dd98f07254951f74ea6f513efe7ff8b hasta antes de 73820561d8cbfd3364a29b8fa77f1707f26029dadesde b66774b48dd98f07254951f74ea6f513efe7ff8b hasta antes de d3afd7803f9bc2a8c4270199497b60158b2fc647desde b66774b48dd98f07254951f74ea6f513efe7ff8b hasta antes de 86b55991d3cd690e73c5ef8d20b75ae4905b357a50c38d9f42a529691e4e67ea9cedf4f0bfc8d277desde 5.10.265 hasta antes de 5.10.273desde 5.15.216 hasta antes de 5.15.224desde 6.1.183 hasta antes de 6.1.191desde 6.6.145 hasta antes de 6.6.161desde 6.12.97 hasta antes de 6.12.115desde 6.18.39 hasta antes de 6.18.60desde 7.1.4 hasta antes de 7.2

• Linux

  7.2

Qué hacer

1. Verificá si usás Linux y en qué versión.
2. Actualizá a la versión corregida que indique el fabricante en su aviso o aplicá su mitigación.
3. Revisá registros y accesos de los sistemas expuestos para descartar un uso previo.

Calculadora CVSS

CVSS 3.1 · 7.8 ALTA

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

• Vector de ataqueLocal
• Complejidad del ataqueBaja
• Privilegios requeridosBajos
• Interacción del usuarioNinguna
• AlcanceSin cambio
• ConfidencialidadAlta
• IntegridadAlta
• DisponibilidadAlta

Descripción original

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: refuse __l2cap_chan_add if chan already has conn l2cap_chan may be linked to l2cap_conn at most once. This is assumed in several places, eg l2cap_chan_del cleanup. There is a TOCTOU race where the invariant is violated: [Task 1] [Task 2] l2cap_chan_connect l2cap_sock_bind l2cap_chan_lock lock_sock l2cap_state_change if (sk->sk_state != BT_OPEN) chan->state = BT_CONNECT l2cap_sock_state_change_cb chan->state = BT_BOUND sk->sk_state = BT_BOUND lock_sock <------------------ release_sock sk->sk_state = BT_CONNECT l2cap_sock_connect() does not check sk->sk_state, so since chan->state is now BT_BOUND, subsequent connect() ends up with second __l2cap_chan_add. Explicitly document and check the invariant in __l2cap_chan_add with WARN_ON_ONCE. The only callsite where it could be hit is l2cap_chan_connect, so add pre-check there to avoid relying on chan->state. chan->state read/write is not properly guarded currently so there can be other TOCTOUC problems. Add l2cap_lock_chan in l2cap_sock_bind() to guard chan->state write.

Referencias (9)

• git.kernel.org/stable/c/85cc289eb08afa975375f838187369e68b429ee0
• git.kernel.org/stable/c/820579652b24ce277e0097cd65b42bd9b7b8bf07
• git.kernel.org/stable/c/e618d928ec7f88cbeadfa3542adcac40f474e629
• git.kernel.org/stable/c/fabaff1c59ff2cc89cb7e5bd0186a5e15f0c73b2
• git.kernel.org/stable/c/52fe88e4ef87311eee32b45c65603e7c69e75e7d
• git.kernel.org/stable/c/10c705dd706aa93164ba41f2566f15206d6c178e
• git.kernel.org/stable/c/73820561d8cbfd3364a29b8fa77f1707f26029da
• git.kernel.org/stable/c/d3afd7803f9bc2a8c4270199497b60158b2fc647
• git.kernel.org/stable/c/86b55991d3cd690e73c5ef8d20b75ae4905b357a

Resumen traducido automáticamente de la descripción original. Fuente: Nureq Monitor. Cómo funciona.