CVE-2026-90091Bluetooth: L2CAP: fix race l2cap_sock_cleanup_listen() vs. put_chan

Official description

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: fix race l2cap_sock_cleanup_listen() vs. put_chan For L2CAP sockets without owning sk->sk_socket, reading l2cap_pi(sk)->chan may race against concurrent l2cap_sock_kill() -> l2cap_sock_put_chan(). This excludes simultaneous proto_ops callbacks, but access in l2cap_sock_cleanup_listen() has unsafe lockless read. [Task 1] [Task 2 (hdev->workqueue)] l2cap_sock_release(parent) l2cap_disconn_cfm l2cap_sock_cleanup_listen l2cap_conn_del bt_accept_dequeue l2cap_chan_del lock_sock(sk) l2cap_sock_teardown_cb bt_accept_unlink bt_sk(sk)->parent = NULL release_sock(sk) ----------------> lock_sock(sk) parent = /* NULL */ lock_sock(sk) <--------------------- release_sock(sk) sock_set_flag(sk, SOCK_ZAPPED) l2cap_sock_close_cb l2cap_sock_kill(sk) l2cap_sock_put_chan chan = READ l2cap_pi(sk)->chan l2cap_pi(sk)->chan = NULL l2cap_chan_hold_unless_zero l2cap_put_chan(chan) kref_get_unless_zero(&chan->ref) Task 1 may observe NULL which causes null-ptr-deref. Fix the race by taking lock_sock() in l2cap_sock_kill() to synchronize with l2cap_sock_cleanup_listen(). hold_unless_zero() is not needed here, l2cap_pi(sk)->chan owns reference if it is non-NULL. Clarify code comments vs. locking.

Affected packages & fixed versions

Affected products (as reported)

References

• https://git.kernel.org/stable/c/827de6bd2865b22aaabd554540def3b8a33018ab
• https://git.kernel.org/stable/c/7c7ac736b50fa259ed1bdddc18d79523f07c0442
• https://git.kernel.org/stable/c/4f8c63fe0097c9f6ea34409f82f79b3894903d91
• https://git.kernel.org/stable/c/61d5ddbd524c715b224cbe7e9f01da4e05098b19
• https://git.kernel.org/stable/c/32a7bc6e93be36b37fe61f351d312d358195bd61
• https://git.kernel.org/stable/c/66d6ef18548ae6d7dd452b84115fc82c0a73a4ea