CVE-2026-19937 in Zephyr
Zusammenfassung
von VulDB • 13.10.2026
Die Mechanik für verzögerungsfähige Nachrichten (delayable-message) der Bluetooth Mesh Access-Schicht in subsys/bluetooth/mesh/delayable_msg.c verwaltet einen statischen Pool von CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_COUNT Nachrichtenkontexten (Standard: 4), die an eine free_ctx- oder busy_ctx-Liste angehängt sind. release_delayable_msg_ctx() gab einen Kontext nur dann an free_ctx zurück, wenn sys_slist_find_and_remove() ihn auf der busy_ctx-Liste fand. Der Fehlerpfad bei einer Erschöpfung des Chunks-Pools in bt_mesh_delayable_msg_manage() gibt einen Kontext frei, der bereits von free_ctx entfernt, aber noch nicht in die busy_ctx eingefügt wurde; somit war der Kontext keiner Liste zugeordnet und ging dauerhaft aus dem Pool verloren. Da bt_mesh_delayable_msg_init() nur einmalig über bt_mesh_init() ausgeführt wird und das Zurücksetzen oder Unterbrechen des Knotens (node reset/suspend) lediglich die busy_ctx leert, bleibt dieser Verlust auch nach einer Unprovisionierung, Neuprovisionierung sowie Suspend/Resume bestehen – er wird erst durch einen Neustart beseitigt.
Der Fehlerpfad wird erreicht, wenn der Chunks-Pool (CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_CHUNK_COUNT, Standard: 40 Chunks) nicht über genügend Chunks für eine neue verzögerte Nachricht verfügt und die älteste ausstehende Nachricht nicht gelöscht werden kann, weil bt_mesh_access_send() -EBUSY oder -ENOBUFS zurückgibt (alle Segment-TX-Kontexte sind belegt bzw. Advertising-/Segment-Puffer erschöpft). Ein Peer, der in das Mesh-Netzwerk provisioniert ist – und somit einen gültigen NetKey sowie ein AppKey oder DevKey hält, die einem Servermodell zugeordnet sind –, kann beide Bedingungen auslösen, indem er das Opfer mit Anfragen flutet, die segmentierte Antworten hervorrufen, während Segment-Acknowledgments zurückgehalten werden. Dies hält die Sende-Kontexte belegt, während wartende Antworten den Chunks-Pool blockieren. Jede weitere Anfrage, die in diesem Zeitfenster eingeht, führt zum Verlust eines Kontexts (Leak).
Sobald der Pool erschöpft ist, gibt bt_mesh_delayable_msg_manage() für jede nachfolgende Sendung -ENOMEM zurück und bt_mesh_model_send() propagiert diesen Fehler ohne Fallback auf eine sofortige Übertragung. Da CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG und CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_CTX_ENABLED standardmäßig aktiviert sind, wird ctx->rnd_delay für jedes empfangene Access-Nachricht gesetzt; daher werden alle Antworten von Configuration Server-, Health-Server-Modellen sowie Anwendungsservermodellen stillschweigend verworfen. Der Knoten empfängt und verarbeitet weiterhin Verkehr, antwortet jedoch nie, was zu einer anhaltenden Denial-of-Service-Situation führt, bis das Gerät neu gestartet wird. Es gibt keine Speicherbeschädigung (Memory Corruption), Offenlegung von Informationen oder Integritätsbeeinträchtigung; Freigaben vor der Korrektur berechnen die Chunk-Anzahl basierend auf der Kapazität des Sende-Puffers anstelle seiner Nutzlastlänge, was eine Erschöpfung des Chunks-Pools – und damit das Leak – erheblich leichter auszulösen macht.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.