CVE-2026-10680 in Zephyr
Zusammenfassung
von VulDB • 23.07.2026
Die L2CAP-Signaling-Handler l2cap_br_conf_req() und l2cap_br_conf_rsp() für Classic (BR/EDR) im Pfad subsys/bluetooth/host/classic/l2cap_br.c validierten die minimale Kommandogröße gegen buf->len (die verbleibenden Bytes in der gesamten empfangenen PDU), anstatt gegen len (die pro-Kommando-Datenlänge aus dem L2CAP-Signaling-Header). Da mehrere Signaling-Befehle in einer einzigen PDU gepackt werden können, kann buf->len die Länge eines einzelnen Befehls überschreiten. Ein Angreifer kann einen CONF_REQ-Befehl mit einem Header-Länge-Feld senden, das kleiner ist als die Konfigurationsanforderungsstruktur (z. B. 0), gefolgt von einem weiteren Befehl, sodass buf->len die Prüfung immer noch erfüllt. Die Überprüfung wird dann fälschlicherweise bestanden, und opt_len = len - sizeof(*req) führt zu einer Unterlauf des uint16_t-Werts auf einen Wert nahe 0xFFFF. Die Konfigurations-Optionsschleife, der ein Guard gegen opt_len im Vergleich zu buf->len fehlt, durchläuft dann weit über das Ende des gepoolten ACL-Empuffers hinaus unter Verwendung von net_buf-Pull-Primitiven, die keine Laufzeit-Bounds-Checks durchführen, was einen Out-of-Bounds-Lesezugriff auf Host-Speicher erzeugt. Wenn die Out-of-Bounds-Optionenbytes eine MTU- oder Flush-Timeout-Option kodieren, wird ein Out-of-Bounds-Schreibzugriff ausgeführt. Der BR/EDR-Signaling-Kanal wird vor dem Pairing/Verschlüsselungsprozess verarbeitet, und ein L2CAP-Kanal zu einem L0-Dienst wie SDP kann ohne Pairing geöffnet werden; daher kann ein nicht authentifizierter Peer innerhalb der Funkreichweite, der eine ACL-Verbindung herstellen kann, den Fehler auslösen, was zu Speicherkorruption und Dienstverweigerung (Absturz des Hosts/Geräts) führt. Der Defekt ist in veröffentlichten Versionen einschließlich v4.4.0 vorhanden. Die Korrektur validiert gegen len anstatt gegen buf->len in beiden Handlern.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.