CVE-2026-90087

/// Technical description

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

Bluetooth: do not leak an hci_conn when a second LE connect is rejected

create_le_conn_complete() decides whether the failed connection is

still pending by comparing it against hci_lookup_le_connect(), which

returns the first LE connection in BT_CONNECT. 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 BT_CONNECT with HCI_CONN_SCANNING set and are invisible to

hci_lookup_le_connect() until hci_le_create_conn_sync() clears the

flag when their command is issued, so the -EBUSY guard in

hci_connect_le() does not prevent a second connection from being

queued while the first is still on the scan path. Whenever two

connections are in BT_CONNECT at once, the lookup may return one

connection while create_le_conn_complete() is reporting the failure

of the other; the early exit then drops the error and hci_conn_failed()

never runs on the conn

/// Remediation

Check the references section for vendor advisories, patches, and mitigation guidance. If immediate patching is not possible, review the CVSS vector to understand the attack surface and apply compensating controls such as network segmentation or access restrictions.

/// References