Answer in brief
CVE-2026-90091 records a Unknown severity vulnerability in Bluetooth: L2CAP: fix race l2cap_sock_cleanup_listen() vs. put_chan. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=b39298044e5534612511a2ff5de03ba5f6e7a820 <827de6bd2865b22aaabd554540def3b8a33018ab || >=8c37e4338c801ebb8cee52436c01c41e009f6e87 <7c7ac736b50fa259ed1bdddc18d79523f07c0442 || >=84e718b6a814edc84159361f9f454a4e92ae91ae <4f8c63fe0097c9f6ea34409f82f79b3894903d91 || >=36da806f7fbaee56ad9e81859deec203f9728700 <61d5ddbd524c715b224cbe7e9f01da4e05098b19 || >=6fef032af0092ed5ccb767239a9ac1bc38c08a40 <32a7bc6e93be36b37fe61f351d312d358195bd61 || >=6fef032af0092ed5ccb767239a9ac1bc38c08a40 <66d6ef18548ae6d7dd452b84115fc82c0a73a4ea || 733e76e74e406c1d1ddc7369420dd8a47f48bb8a || >=6.1.178 <6.1.188 || >=6.6.145 <6.6.157 || >=6.12.97 <6.12.110 || >=6.18.40 <6.18.52 || >=7.1.5 <7.2 | 827de6bd2865b22aaabd554540def3b8a33018ab, 7c7ac736b50fa259ed1bdddc18d79523f07c0442, 4f8c63fe0097c9f6ea34409f82f79b3894903d91, 61d5ddbd524c715b224cbe7e9f01da4e05098b19, 32a7bc6e93be36b37fe61f351d312d358195bd61, 66d6ef18548ae6d7dd452b84115fc82c0a73a4ea, 6.1.188, 6.6.157, 6.12.110, 6.18.52, 7.2 |
| Linux/Linuxgeneric | 7.2 | Not reported |
Published upstream
Sep 17, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Sep 17, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Sep 17, 2026
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.
Quoted source text, attributed separately from HOL analysis.