CVE-2026-90092
Received
Received - Intake
BaseFortify
Vulnerability report for CVE-2026-90092, including description, CVSS score, EPSS score, affected products, exploitability, helpful resources, and attack-flow context.
Publication date: 2026-09-17
Last updated on: 2026-09-18
Assigner: kernel.org
Description
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.
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
Currently, no data is known.
Helpful Resources
Exploitability
CWE
KEV
| CWE ID | Description |
|---|---|
| CWE-UNKNOWN |
