CVE-2026-99239

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