Odebrany

CVE-2026-90087

opublikowano: 17.09.2026, 19:16

modyfikacja: 17.09.2026, 19:16

Ocena CVSS

n/a

Brak oceny

Oficjalne źródła

>_ Opis

Tłumaczenie automatyczne – może zawierać nieścisłości.

W jądrze Linuksa usunięto następującą lukę:

Bluetooth: nie wyciekaj hci_conn, gdy drugie połączenie LE zostanie odrzucone

create_le_conn_complete() decyduje, czy nieudane połączenie jest
wciąż w toku, porównując go z hci_lookup_le_connect(), który
zwraca pierwsze połączenie LE w BT_CONNECT. To jest to samo
połączenie tylko wtedy, gdy co najwyżej jedno jest w toku.

Dwa mogą być w toku. Połączenia utworzone na pasywnej ścieżce skanowania znajdują się
w BT_CONNECT z ustawionym HCI_CONN_SCANNING i są dla nich niewidoczne
hci_lookup_le_connect() do czasu, aż hci_le_create_conn_sync() usunie
flagę po wydaniu polecenia, więc opcja -EBUSY zostanie włączona
hci_connect_le() nie zapobiega nawiązaniu drugiego połączenia
w kolejce, gdy pierwszy nadal znajduje się na ścieżce skanowania. Kiedykolwiek dwa
połączenia są jednocześnie w BT_CONNECT, wyszukiwanie może zwrócić jedno
połączenie, podczas gdy funkcja create_le_conn_complete() zgłasza błąd
z drugiego; wczesne wyjście powoduje następnie usunięcie błędu i hci_conn_failed()
nigdy nie działa na połączeniu, które uległo awarii.

Kontroler odrzuca również drugie wydane HCI_OP_LE_CREATE_CONN
podczas gdy utworzenie kolejnego połączenia jest nadal niewykonane, zgodnie ze specyfikacją rdzenia
Tom 4, część E. Specyfikacja wymaga tam zakazu poleceń; the
bcm43438 zaobserwowany tutaj odpowiada zamiast tego kodem błędu LMP/LL,
które bt_to_errno() odwzorowuje -EPROTO (-71) w poniższym dzienniku.

Wyciekające połączenie pozostaje w BT_CONNECT na zawsze i dlatego
hci_connect_le() odmawia wybierania numeru, podczas gdy hci_lookup_le_connect() znajduje
czegokolwiek, każda kolejna próba dotarcia do dowolnego partnera kończy się niepowodzeniem
-EBUSY i żadne polecenie nie dociera w ogóle do kontrolera.

Widziane na bcm43438 z dwoma urządzeniami równorzędnymi BLE odpytywanymi w tym samym odstępie czasu
(stan 5 to BT_CONNECT; oba uchwyty są UNSET, przydzielone z
ida powyżej HCI_CONN_HANDLE_MAX):

Bluetooth: hci1: Kod operacji 0x2013 nie powiódł się: -71

# hcitool con
< LE 14:9C:EF:03:68:81 klamka 3840 stan 5 mb CENTRALNY
< LE C4:D3:6A:8C:B5:38 klamka 3841 stan 5 mb CENTRALNY

Przechwytywanie btmon w ciągu następnych dziesięciu minut prób połączenia
w ogóle nie zawiera HCI_OP_LE_CREATE_CONN; połączenia wychodzące LE
nie przywróć danych, dopóki adapter nie zostanie zresetowany. Z tą zmianą to samo
scenariusz kończy się niepowodzeniem odrzuconego połączenia i dalsze nawiązanie połączenia
aby obaj partnerzy przeszli.

Zapytaj o samo połączenie, a nie o urządzenie.

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 connection that failed.

The controller also rejects a second HCI_OP_LE_CREATE_CONN 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 bt_to_errno() maps to the -EPROTO (-71) in the log below.

The leaked connection stays in BT_CONNECT forever, and because
hci_connect_le() refuses to dial while hci_lookup_le_connect() 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 BT_CONNECT; both handles are UNSET ones, allocated from
the ida above HCI_CONN_HANDLE_MAX):

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 HCI_OP_LE_CREATE_CONN 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.

>_ Referencje

Dane podatności pochodzą z oficjalnych źródeł (CVE® List / NVD). Opisy po polsku są tłumaczone automatycznie i mogą zawierać nieścisłości – na stronie rekordu można wyświetlić wersję angielską.

This product uses the NVD API but is not endorsed or certified by the NVD.

CVE Usage: MITRE hereby grants you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Common Vulnerabilities and Exposures (CVE®). Any copy you make for such purposes is authorized provided that you reproduce MITRE's copyright designation and this license in any such copy. ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN PROVIDED BY MITRE ARE PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND.

NVD Terms of Use / CVE® Terms of Use / nvd.nist.gov / cve.org

<< baza_cve