CVE-2026-90092

01/Description

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: reject accept queue add unless BT_LISTEN New sk should not be added to parent socket accept queue after last l2cap_sock_cleanup_listen() has run in l2cap_sock_teardown_cb() and state set to BT_CLOSED, as that can result to UAF on dereferencing the dangling parent reference. l2cap_sock_new_connection_cb() may race with parent l2cap_chan teardown, due to chan->state accessed without consistent locking: [Task 1] [Task 2] l2cap_sock_release(parent) l2cap_connect l2cap_sock_shutdown pchan = l2cap_global_chan_by_psm l2cap_chan_lock(pchan) l2cap_chan_close l2cap_sock_teardown_cb pchan->state = BT_CLOSED l2cap_chan_unlock(pchan) ------> l2cap_chan_lock(pchan) l2cap_new_connection l2cap_sock_new_connection_cb l2cap_chan_lock(pchan) <-------- l2cap_chan_unlock(pchan) l2cap_sock_kill(parent) /* bt_sk(sk)->parent dangling */ Fix by adding check for sk_state == BT_LISTEN after acquiring sk lock in l2cap_sock_new_connection_cb(). Add lock_sock() around sk_state writes where missing, to avoid data races. Although the data races on pchan->state should be fixed too, this defensive sk_state check probably makes sense in any case.

02/References6

• git.kernel.org/stable/c/2a3a27aaf19bf069720e024ce6fde54e6bf80df9
• git.kernel.org/stable/c/491e4c60017969b053888029998d2a61f298986a
• git.kernel.org/stable/c/87276dc15b559d32757a43b4415c8445fbae06c4
• git.kernel.org/stable/c/bf61a65c6093970e3b50031c4b79ebf3bd411eba
• git.kernel.org/stable/c/c47339e169bf4a0a4cfabb91351471f67744c2bc
• git.kernel.org/stable/c/d4bfa78fd67929b62b02013c107973e0c5b7aa9a