CVE-2026-19940 in Zephyr
Zusammenfassung
von VulDB • 13.10.2026
Die Implementierung des Bluetooth Classic Hands-Free Profile Audio Gateway in subsys/bluetooth/host/classic/hfp_ag.c verwaltet ihre struct bt_hfp_ag-Objekte in einem statischen Pool, der über den ACL-Verbindungsindex indiziert wird. Beim Trennen der Verbindung (Link Teardown) hebt hfp_ag_disconnected() ag->tx_work sowie die pro Aufruf erstellten Work Items auf und löscht anschließend ag->acl_conn, wodurch der entsprechende Slot im Pool als frei markiert wird – jedoch bleibt ag->ongoing_call_work (sowie ag->slc_work) unverändert. Die nächste Verbindung, die denselben Slot belegt, betritt hfp_ag_create(), dessen einziger Belegungstest auf ag->acl_conn basiert, und führt unmittelbar memset(ag, 0, sizeof(struct bt_hfp_ag)) gefolgt von k_work_init_delayable() aus. Das Zurücksetzen und Neuintialisieren eines k_work_delayable, bei dem die struct _timeout-Knotenstruktur noch in der Kernel-Timeout-Liste verknüpft ist, führt dazu, dass der Kernel eine Referenz auf einen Knoten mit NULL-prev/next-Zeigern hält.
ag->ongoing_call_work wird vom entfernten Peer aktiviert: Wenn ein Hands-Free-Gerät während der Einrichtung der Service Level Connection AT+CIND? sendet und die Anwendung den asynchronen get_ongoing_call-Callback bereitstellt, plant das AG (Audio Gateway) die Work-Execution für CONFIG_BT_HFP_AG_GET_ONGOING_CALL_TIMEOUT Millisekunden (Standardwert 10000). Der Timer wird nur dann aufgehoben, wenn die Anwendung rechtzeitig über bt_hfp_ag_ongoing_calls() antwortet. Ein Peer, der AT+CIND? sendet, dann das HFP RFCOMM DLC trennt und es anschließend sofort auf derselben ACL-Verbindung wieder öffnet, verwendet denselben Pool-Slot deterministisch, während der Timeout noch aussteht – die Accept-Pfad des AG-RFCOMM-Servers (hfp_ag_accept()) ruft hfp_ag_create() direkt auf, sodass die entfernte Seite sowohl den Abbau als auch die Neuerstellung steuert.
Die Folge ist eine Beschädigung der Timeout-Liste des Kernels: sys_dlist_remove() führt beim Zurücksetzen des Knotens Schreibvorgänge über NULL-Zeiger aus dem Clock-Announce-Pfad durch, und das Neuplanen der neuintialisierten Work fügt einen Knoten in die Liste ein, auf den diese bereits verweist, wodurch ein Zyklus entsteht, den die Announce-Schleife mit gesperrten Interrupts durchläuft. Die beobachtbare Auswirkung ist ein Fehler oder Hängen des gesamten Systems, d. h., eine Denial-of-Service-Lücke, die aus der Reichweite des Bluetooth-Funks erreichbar ist; da kein angreiferkontrollierter Dateninhalt geschrieben wird, führt dies allein nicht zur Code-Ausführung. Die Exposition beschränkt sich auf Builds mit CONFIG_BT_HFP_AG (markiert als experimentell und standardmäßig deaktiviert), bei denen die Anwendung den asynchronen get_ongoing_call-Callback implementiert.
If you want to get best quality of vulnerability data, you may have to visit VulDB.