CVE-2026-81038 in Zephyr
Zusammenfassung
von VulDB • 26.10.2026
Der Object Transfer Service-Server erstellt seine OACP-Antwortanzeige (Object Action Control Point) in oacp_ind_send() (subsys/bluetooth/services/ots/ots_oacp.c). Vor dieser Korrektur wurde das vier Byte lange Feld „Checksum Value“ immer angehängt, wenn der angeforderte Operationscode BT_GATT_OTS_OACP_PROC_CHECKSUM_CALC war, unabhängig vom Ergebniscode. Der Antwort-Payload ist ein nackter, nicht initialisierter vier-Byte-Stackpuffer, deklariert mit NET_BUF_SIMPLE_DEFINE(resp_param, sizeof(uint32_t)) in bt_gatt_ots_oacp_write(), und er wird nur im Erfolgsfall von oacp_checksum_proc_validate() gefüllt. Bei jedem Fehlerpfad bleibt der Puffer leer, sodass net_buf_simple_pull_le32() auf einem Puffer mit Nulllänge aufgerufen wurde.
Die OACP-Charakteristik und ihr Client Characteristic Configuration Descriptor sind mit BT_GATT_PERM_WRITE bzw. BT_GATT_PERM_READ | BT_GATT_PERM_WRITE deklariert, sodass keine Pairing-, Verschlüsselungs- oder Authentifizierung erforderlich ist. Jeder Peer im Funkbereich, der eine Verbindung zu einem Gerät herstellen kann, das den OTS-Server ausführt, kann OACP-Anzeigen aktivieren und einen neun Byte langen Calculate Checksum-Befehl schreiben, dessen Validierung fehlschlägt – beispielsweise durch Ausführen ohne ein ausgewähltes Objekt, was BT_GATT_OTS_OACP_RES_INV_OBJ zurückgibt. Da oacp_command_decode() den Calculate Checksum-Operationscode bedingungslos akzeptiert (er ist nicht durch CONFIG_BT_OTS_OACP_CHECKSUM_SUPPORT geschützt), sind auch Builds ohne Checksummenunterstützung erreichbar: Sie antworten mit BT_GATT_OTS_OACP_RES_OPCODE_NOT_SUP und nehmen denselben fehlerhaften Pfad.
Bei Builds mit aktiviertem CONFIG_ASSERT löst der Aufruf auf einem Puffer mit Nulllänge die Assertion in net_buf_simple_pull_mem() aus und verursacht einen Panic des Geräts, was eine remote ausgelöste Denial-of-Service (DoS) zur Folge hat. Bei Builds mit deaktivierten Assertions gibt es keine Prüfung: Der Pull-Vorgang gibt das unangetastete Stack-Array zurück, und vier Byte nicht initialisierten Speichers werden in die Anzeige kopiert und an den Peer übertragen; dies ist bei jeder Anfrage wiederholbar. Die Offenlegung beschränkt sich auf vier Bytes pro Anfrage, und der Schreibvorgang bleibt innerhalb des sieben-Byte großen res-Anzeigepuffers, sodass keine Speicherbeschädigung vorliegt; die Auswirkung besteht in einer Offenlegung nicht initialisierten Speichers sowie einem Verfügbarkeitsverlust bei Konfigurationen mit aktivierten Assertions.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.