CVE-2026-90092: Bluetooth: L2CAP: reject accept queue add unless BT_LISTEN

Published Sep 17, 2026
·
Updated

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: L2CAP: reject accept queue add unless BTLISTEN

New sk should not be added to parent socket accept queue after last l2capsockcleanuplisten() has run in l2capsockteardowncb() and state set to BTCLOSED, as that can result to UAF on dereferencing the dangling parent reference.

l2capsocknewconnectioncb() may race with parent l2capchan teardown, due to chan->state accessed without consistent locking:

[Task 1] [Task 2] l2capsockrelease(parent) l2capconnect l2capsockshutdown pchan = l2capglobalchanbypsm l2capchanlock(pchan) l2capchanclose l2capsockteardowncb pchan->state = BTCLOSED l2capchanunlock(pchan) ------> l2capchanlock(pchan) l2capnewconnection l2capsocknewconnectioncb l2capchanlock(pchan) <-------- l2capchanunlock(pchan) l2capsockkill(parent) / btsk(sk)->parent dangling /

Fix by adding check for skstate == BTLISTEN after acquiring sk lock in l2capsocknewconnectioncb(). Add locksock() around skstate writes where missing, to avoid data races.

Although the data races on pchan->state should be fixed too, this defensive skstate check probably makes sense in any case.

Affected Software

1 affected component
Linux Linux kernel

Event History

Sep 17, 2026
CVE Published
via MITRE·04:06 PM
Data Sourced
via MITRE·04:06 PM
Description

Frequently Asked Questions

1

What conditions are required to trigger this issue?

A race must occur between teardown of an L2CAP parent socket that was listening and creation of a new L2CAP connection. The new connection callback can otherwise add a child socket to the parent accept queue after the parent has been closed and its parent reference has become dangling.

2

Which Linux systems are exposed?

Systems using the Linux kernel Bluetooth L2CAP socket handling are relevant. The provided information does not identify affected kernel versions, configurations, or whether Bluetooth must be enabled and in active use.

3

How does the fix prevent the use-after-free?

The fix checks that the socket state is still BT_LISTEN after acquiring the socket lock before adding a new socket to the accept queue. It also adds socket locking around previously unprotected socket-state writes to prevent data races.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203