Średni Oczekuje na analizę

CVE-2026-85036

opublikowano: 04.11.2026, 07:17

modyfikacja: 04.11.2026, 07:17

Ocena CVSS

5.7

Średni · v3.1

Oficjalne źródła

wektor: CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

>_ Opis

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

Warstwa Bluetooth Classic AVDTP opóźnia zwolnienie punktów końcowych strumienia sesji: bt_avdtp_l2cap_disconnected() w subsys/bluetooth/host/classic/avdtp.c kończy się k_work_submit(&session->_release_work), umieszczając osadzoną strukturę k_work na systemowej liście oczekujących kolejki roboczej. Kiedy ten sam obiekt struct bt_avdtp jest natychmiast ponownie używany w nowym połączeniu sygnalizacyjnym, pamięć sesji jest ponownie inicjowana — a2dp_get_connection() w subsys/bluetooth/host/classic/a2dp.c memset()s cała struktura bt_a2dp i bt_avdtp_l2cap_accept() / bt_avdtp_connect() wywołuje k_work_init() w sesji->_release_work — podczas gdy ten element pracy jest nadal połączony z k_sys_work_q.pending. Zerowanie połączonego sys_snode_t obcina listę, podczas gdy jej wskaźnik końcowy wskazuje poza obcięcie.

Okno ponownego użycia ma charakter deterministyczny, a nie wyścigowy. Całe przetwarzanie RX hosta odbywa się w kolejce roboczej Bluetooth RX z priorytetem kooperacyjnym (CONFIG_BT_RX_PRIO), podczas gdy _release_work jest przesyłane do systemowej kolejki roboczej o niższym priorytecie, więc procedura obsługi wydania nie może zostać uruchomiona, dopóki wątek RX nie zostanie zablokowany. Ponieważ funkcja l2cap_br_recv() przetwarza każde polecenie sygnalizacyjne zawarte w pojedynczej sygnalizacyjnej jednostce PDU L2CAP, uczestnik może wysłać jedną jednostkę PDU zawierającą żądanie rozłączenia L2CAP dla kanału sygnalizacyjnego AVDTP, po którym następuje żądanie połączenia dla PSM 0x0019; drugie polecenie dociera do ścieżki ponownego wykorzystania sesji, a prace nad wydaniem prawdopodobnie nadal znajdują się w kolejce. Uczestnik musi już posiadać zaszyfrowany kanał sygnalizacyjny AVDTP, tj. być sparowanym/połączonym urządzeniem BR/EDR.

Rezultatem jest uszkodzenie listy oczekujących kolejek roboczych systemu globalnego: albo kolejka po cichu przestaje w ogóle wykonywać jakąkolwiek pracę (kolejne przesłania są dołączane do łańcucha, do którego głowa nie może już dotrzeć, a osierocone elementy zachowują na zawsze swoją flagę K_WORK_QUEUED) lub, w wariancie końcowym, lista uzyskuje węzeł samoodwołujący się, na którym obraca się wątek kolejki. Zapisane wartości są wskaźnikami do innych obiektów struct k_work i nie są kontrolowane przez osobę atakującą, więc skutkiem jest odmowa usługi obejmująca całe urządzenie i wymagająca ponownego uruchomienia, a nie kontrolowany prymityw zapisu. Dotyczy to tylko kompilacji z CONFIG_BT_CLASSIC i CONFIG_BT_A2DP.

Poprawka składa się z dwóch zatwierdzeń i żadne z zatwierdzeń nie zamyka ścieżki samodzielnie. ec822ceed83b dodaje kontrolę oczekującego wydania do bt_avdtp_connect() i bt_avdtp_l2cap_accept(), ale funkcja a2dp_get_connection() memset() górnej warstwy A2DP sprawdza sesję — łącznie z węzłem listy i flagami oczekującego elementu roboczego w kolejce — przed uruchomieniem tych kontroli, więc k_work_busy_get() zaobserwuje już wyczyszczoną stan. 2bd5ea88c69b zamyka to, sprawiając, że sama a2dp_get_connection() pomija ponowne użycie i zwraca NULL, gdy prace nad wydaniem są nadal w toku, co oba obiekty wywołujące już obsługują, odrzucając próbę połączenia. Zastosuj oba zatwierdzenia razem; każdy z nich sam naraża urządzenie na niebezpieczeństwo.

The Bluetooth Classic AVDTP layer defers releasing a session's stream endpoints: bt_avdtp_l2cap_disconnected() in subsys/bluetooth/host/classic/avdtp.c ends with k_work_submit(&session->_release_work), placing the embedded struct k_work on the system work queue's pending list. When the same struct bt_avdtp object is immediately reused for a new signalling connection, the session memory is re-initialized — a2dp_get_connection() in subsys/bluetooth/host/classic/a2dp.c memset()s the whole struct bt_a2dp, and bt_avdtp_l2cap_accept() / bt_avdtp_connect() call k_work_init() on session->_release_work — while that work item is still linked into k_sys_work_q.pending. Zeroing a linked sys_snode_t truncates the list while its tail pointer keeps pointing past the truncation.

The reuse window is deterministic rather than a race. All host RX processing runs on the Bluetooth RX work queue at a cooperative priority (CONFIG_BT_RX_PRIO), while _release_work is submitted to the lower-priority system work queue, so the release handler cannot run until the RX thread blocks. Because l2cap_br_recv() processes every signalling command contained in a single L2CAP signalling PDU back-to-back, a peer can send one PDU holding an L2CAP Disconnection Request for the AVDTP signalling channel followed by a Connection Request for PSM 0x0019; the second command reaches the session-reuse path with the release work provably still queued. The peer must already hold an encrypted AVDTP signalling channel, i.e. be a paired/bonded BR/EDR device.

The result is corruption of the global system work queue's pending list: either the queue silently stops executing any work at all (subsequent submissions are appended to a chain the head can no longer reach, and the orphaned items keep their K_WORK_QUEUED flag forever) or, in the tail variant, the list acquires a self-referencing node that the queue thread spins on. The written values are pointers to other struct k_work objects and are not attacker-controlled, so the impact is a device-wide, reboot-required denial of service rather than a controllable write primitive. Only builds with CONFIG_BT_CLASSIC and CONFIG_BT_A2DP are affected.

The fix is a two-commit unit, and neither commit closes the path on its own. ec822ceed83b adds a pending-release check to bt_avdtp_connect() and bt_avdtp_l2cap_accept(), but the A2DP upper layer's a2dp_get_connection() memset()s the session — including the queued work item's list node and flags — before those checks run, so k_work_busy_get() would observe an already-cleared state. 2bd5ea88c69b closes that by making a2dp_get_connection() itself skip the reuse and return NULL while the release work is still pending, which both callers already handle by rejecting the connection attempt. Apply both commits together; either one alone leaves the device vulnerable.

>_ Słabości (CWE)

CWE-666

>_ 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