CVE-2026-90087: Bluetooth: do not leak an hci_conn when a second LE connect is rejected
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: do not leak an hciconn when a second LE connect is rejected
createleconncomplete() decides whether the failed connection is still pending by comparing it against hcilookupleconnect(), which returns the first LE connection in BTCONNECT. That is the same connection only while at most one is pending.
Two can be pending. Connections created on the passive scan path sit in BTCONNECT with HCICONNSCANNING set and are invisible to hcilookupleconnect() until hcilecreateconnsync() clears the flag when their command is issued, so the -EBUSY guard in hciconnectle() does not prevent a second connection from being queued while the first is still on the scan path. Whenever two connections are in BTCONNECT at once, the lookup may return one connection while createleconncomplete() is reporting the failure of the other; the early exit then drops the error and hciconnfailed() never runs on the connection that failed.
The controller also rejects a second HCIOPLECREATECONN issued while another connection creation is still outstanding, per Core Spec Vol 4, Part E. The spec calls for Command Disallowed there; the bcm43438 observed here answers with an LMP/LL error code instead, which bttoerrno() maps to the -EPROTO (-71) in the log below.
The leaked connection stays in BTCONNECT forever, and because hciconnectle() refuses to dial while hcilookupleconnect() finds anything, every subsequent attempt to reach any peer fails with -EBUSY and no command reaches the controller at all.
Seen on a bcm43438 with two BLE peers polled on the same interval (state 5 is BTCONNECT; both handles are UNSET ones, allocated from the ida above HCICONNHANDLEMAX):
Bluetooth: hci1: Opcode 0x2013 failed: -71
# hcitool con < LE 14:9C:EF:03:68:81 handle 3840 state 5 lm CENTRAL < LE C4:D3:6A:8C:B5:38 handle 3841 state 5 lm CENTRAL
A btmon capture across the next ten minutes of connect attempts contains no HCIOPLECREATECONN at all; outgoing LE connections do not recover until the adapter is reset. With this change the same scenario fails the rejected connection cleanly and further connects to both peers go through.
Ask about the connection itself instead of about the device.
Affected Software
Event History
Frequently Asked Questions
Under what condition can the connection leak occur?
It can occur when two LE connections are simultaneously in the BT_CONNECT state. A connection created through the passive scan path can remain in BT_CONNECT with HCI_CONN_SCANNING set, allowing a second connection to be queued before the first connection command is issued.
What does an attacker or triggering condition need to cause the issue?
The issue is triggered by a second LE connection attempt being rejected while another LE connection creation is still outstanding. The Bluetooth controller rejects a second HCI_OP_LE_CREATE_CONN command in that situation.
How does the failed connection end up leaked?
The completion handler can look up a different pending LE connection than the one whose creation failed. It then exits early, dropping the error instead of calling hci_conn_failed() for the failed connection.