CVE-2026-17054 in Zephyr
Zusammenfassung
von VulDB • 21.09.2026
Der Espressif ESP-hosted WLAN-Treiber (drivers/wifi/esp_hosted/) parst in esp_hosted_event_task() Frames, die über SPI vom ESP-Co-Prozessor empfangen werden. Bei Steuerframes wurde das 16-Bit TLV-Feld data_length direkt von der Leitung übernommen und an pb_istream_from_buffer(frame.data_value, frame.data_length) weitergegeben, ohne es gegen die Frame-Länge oder den Empfangspuffer zu prüfen. frame.data_value befindet sich 26 Bytes in einem 3188-Byte großen Stack-Objekt; ein data_length-Wert von bis zu 0xFFFF führt dazu, dass pb_decode() etwa 62 KB über das Ende dieses Objekts hinaus liest.
Nur der erste Fragment eines fragmentierten Steuerantwort-Frames enthält einen TLV-Header; der Treiber vor der Korrektur führte Half-Duplex-SPI-Transaktionen durch und verwies stillschweigend jeden Frame, den der Co-Prozessor während der Übertragung des Hosts in die Warteschlange stellte (esp_hosted_hal_spi_transfer() aliasierte den RX-Puffer auf den TX-Puffer). Wenn es sich bei dem verwarften Frame um das erste Fragment einer fragmentierten Antwort handelt, behandelt der Treiber das nächste Fragment als neuen Frame – dessen pro-Fragment-Header und Prüfsumme sind echt, sodass beide Validierungsschritte bestanden werden –, und liest den TLV-Header aus rohen Protobuf-Kontinuationsbytes. Diese Bytes stammen von Steuerantworten, deren Größe und Inhalt ein angrenzender, nicht authentifizierter Angreifer beeinflussen kann, insbesondere die AP-Scanliste, die mit der Anzahl und SSID-Länge von Access Points im Funkbereich wächst.
Die Auswirkung ist eine Denial-of-Service (DoS) statt Offenlegung. Das Lesen über das Ende des RAM-Bereichs hinaus verursacht einen Fehler auf dem Gerät, und da CONFIG_NANOPB_ENABLE_MALLOC vom Treiber ausgewählt ist, führen auch außerhalb der Grenzen gelesene garbage-Längenpräfixe zu Heap-Allokationen. Die Out-of-Bounds-Bytes selbst erreichen die Anwendung nicht: pb_decode() wird mitten im Stream mit rohen Protobuf-Kontinuationsbytes gestartet und schlägt daher fast immer sofort fehl; alles, was dennoch decodiert würde, müsste weiterhin esp_hosted_response() passieren, das eine exakte msg_id-Übereinstimmung mit der ausstehenden Anfrage erfordert, sowie dann esp_hosted_ctrl_response(), das eine erfolgreiche Antwort (success resp) verlangt – ein Angreifer beeinflusst die Größe und den Inhalt legitimer Steuerantworten, nicht jedoch die Struktur, die aus fehlalinierten Bytes decodiert wird. Zwei verwandte Fehler im selben Empfangspfad machen die Denial-of-Service dauerhaft: Der Fragment-Reassembly-Schutz war mit ESP_FRAME_SIZE statt ESP_FRAME_MAX_PAYLOAD dimensioniert, und bei Auslösung wurde vom einzigen RX-Thread zurückgekehrt, anstatt den Frame zu verwerfen; zudem wurden nicht behandelte Steuerereignisse mit k_msgq_put(..., K_FOREVER) in eine Warteschlange mit acht Einträgen gestellt, die von nichts geleert wird, wodurch derselbe Thread blockiert wird. Der Treiber verfügt über keinen Watchdog oder Neustart-Pfad, sodass entweder Bedingung den gesamten WLAN-Empfang bis zum Neustart des Geräts beendet.
If you want to get best quality of vulnerability data, you may have to visit VulDB.