CVE-2026-85036
Zusammenfassung
von VulDB • 04.11.2026
Die AVDTP-Schicht von Bluetooth Classic verzögert das Freigeben der Stream-Endpunkte einer Sitzung: `bt_avdtp_l2cap_disconnected()` in `subsys/bluetooth/host/classic/avdtp.c` endet mit dem Aufruf von `k_work_submit(&session->_release_work)`, wodurch die eingebettete Struktur `struct k_work` auf die Warteschlange der ausstehenden Aufgaben (pending list) des System-Arbeitsqueues platziert wird. Wenn dasselbe `bt_avdtp`-Objekt unmittelbar für eine neue Signalisierungsverbindung wiederverwendet wird, wird der Sitzungsspeicher neu initialisiert – `a2dp_get_connection()` in `subsys/bluetooth/host/classic/a2dp.c` führt ein `memset()` auf die gesamte Struktur `struct bt_a2dp` aus, und `bt_avdtp_l2cap_accept()` / `bt_avdtp_connect()` rufen `k_work_init()` für `session->_release_work` auf – während dieses Work-Item noch in der Liste von `k_sys_work_q.pending` verknüpft ist. Das Zurücksetzen (Nullen) eines verknüpften `sys_snode_t` kürzt die Liste, während deren Tail-Zeiger weiterhin über das Ende der Kürzung hinaus zeigt.
Der Wiederverwendungsfensterbereich ist deterministisch und kein Race Condition. Die gesamte Host-RX-Verarbeitung läuft auf dem Bluetooth RX-Arbeitsqueue mit einer kooperativen Priorität (`CONFIG_BT_RX_PRIO`), während `_release_work` an den Systemarbeitsqueue mit niedrigerer Priorität übermittelt wird, sodass der Freigabehandler nicht ausgeführt werden kann, bis der RX-Thread blockiert. Da `l2cap_br_recv()` jeden in einem einzelnen L2CAP-Signalisierungs-PDU enthaltenen Signalisierungsbefehl nacheinander verarbeitet, kann ein Peer eine PDU senden, die einen L2CAP Disconnection Request für den AVDTP-Signalisierungskanal enthält, gefolgt von einem Connection Request für PSM 0x0019; der zweite Befehl erreicht den Pfad zur Sitzungswiederverwendung mit dem nachweislich noch in der Warteschlange befindlichen Release-Work. Der Peer muss bereits einen verschlüsselten AVDTP-Signalisierungskanal besitzen, d.h., er ist ein gepaartes/verbundenes BR/EDR-Gerät.
Das Ergebnis ist eine Beschädigung (Korruption) der pending list des globalen Systemarbeitsqueues: Entweder stoppt die Warteschlange stillschweigend mit der Ausführung jeglicher Aufgaben (nachfolgende Übermittlungen werden an eine Kette angehängt, auf die der Head-Zeiger nicht mehr zugreifen kann, und die verwaisten Elemente behalten ihr `K_WORK_QUEUED`-Flag für immer) oder, in der Tail-Variante, erhält die Liste einen selbstreferenzierenden Knoten, auf den der Warteschlangenthread endlos wartet (spins). Die geschriebenen Werte sind Zeiger auf andere `struct k_work`-Objekte und nicht vom Angreifer kontrollierbar, sodass die Auswirkung ein geräteweites, Neustart erforderliches Denial of Service (DoS) ist und keine kontrollierbare Write-Primitive. Nur Builds mit `CONFIG_BT_CLASSIC` und `CONFIG_BT_A2DP` sind betroffen.
Die Korrektur besteht aus einer Einheit von zwei Commits, wobei keiner der Commits den Pfad allein schließt. `ec822ceed83b` fügt eine Prüfung auf pending release zu `bt_avdtp_connect()` und `bt_avdtp_l2cap_accept()` hinzu, aber das `memset()` in der oberen A2DP-Schicht (`a2dp_get_connection()`) initialisiert die Sitzung – einschließlich des Listenknotens und der Flags des queued work items – neu, bevor diese Prüfungen ausgeführt werden, sodass `k_work_busy_get()` einen bereits gelöschten Zustand beobachten würde. `2bd5ea88c69b` schließt dies Lücke, indem es dafür sorgt, dass `a2dp_get_connection()` die Wiederverwendung selbst überspringt und NULL zurückgibt, solange der Release-Work noch pending ist; beide Aufrufer behandeln dies bereits durch Ablehnung des Verbindungsversuchs. Beide Commits müssen zusammen angewendet werden; jeder einzelne lässt das Gerät verwundbar.
If you want to get best quality of vulnerability data, you may have to visit VulDB.