CVE-2026-17054 in Zephyr
Summary
by MITRE • 09/22/2026
The Espressif ESP-hosted Wi-Fi driver (drivers/wifi/esp_hosted/) parses frames received over SPI from the ESP co-processor in esp_hosted_event_task(). For control frames it took the 16-bit TLV field data_length straight off the wire and passed it to pb_istream_from_buffer(frame.data_value, frame.data_length) without checking it against the frame length or the receive buffer. frame.data_value sits 26 bytes into a 3188-byte stack object, so a data_length of up to 0xFFFF makes pb_decode() read up to roughly 62 KB past the end of that object.
Only the first fragment of a fragmented control response carries a TLV header; the pre-fix driver performed half-duplex SPI transactions and silently discarded any frame the co-processor queued while the host was transmitting (esp_hosted_hal_spi_transfer() aliased the RX buffer onto the TX buffer). When the discarded frame is the first fragment of a fragmented response, the driver treats the next fragment as a new frame — its per-fragment header and checksum are genuine, so both validation steps pass — and reads the TLV header out of raw protobuf continuation bytes. Those bytes come from control responses whose size and content an adjacent, unauthenticated attacker can influence, notably the AP scan list, which grows with the number and SSID length of access points in radio range.
The impact is denial of service rather than disclosure. Reading past the end of the RAM region faults the device, and CONFIG_NANOPB_ENABLE_MALLOC is selected by the driver, so garbage length prefixes read out of bounds also drive heap allocations. The out-of-bounds bytes themselves do not reach the application: pb_decode() is started mid-stream on raw protobuf continuation bytes and so almost always fails outright, and anything that did decode would still have to pass esp_hosted_response(), which requires an exact msg_id match against the pending request, and then esp_hosted_ctrl_response(), which requires a success resp — an attacker influences the size and content of legitimate control responses, not the structure decoded out of misaligned bytes. Two related defects in the same receive path make the denial of service permanent: the fragment reassembly guard was sized with ESP_FRAME_SIZE instead of ESP_FRAME_MAX_PAYLOAD and, when tripped, returned from the sole RX thread instead of dropping the frame, and unhandled control events were queued with k_msgq_put(..., K_FOREVER) on an eight-entry queue that nothing drains, blocking that same thread. The driver has no watchdog or restart path, so either condition ends all Wi-Fi reception until the device is rebooted.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/22/2026
The Espressif ESP-hosted Wi-Fi driver contains a critical out-of-bounds read vulnerability within its SPI frame parsing logic, specifically in the esp_hosted_event_task function. This flaw arises when processing control frames received from an ESP co-processor over the Serial Peripheral Interface bus. The driver extracts a 16-bit Type-Length-Value field data_length directly from the wire without validating it against the actual length of the incoming frame or the available space within the receive buffer. Consequently, if a maliciously crafted frame specifies a large data_length value, such as the maximum uint16_t value of 0xFFFF, the subsequent call to pb_istream_from_buffer instructs the protobuf decoder to read up to approximately sixty-two kilobytes beyond the end of the stack-allocated object where frame.data_value resides. This buffer is located twenty-six bytes into a three-thousand-one-hundred-and-eighty-eight-byte stack variable, making the out-of-bounds access both significant and dangerous.
The vulnerability is exploitable due to specific conditions in how fragmented control responses are handled by the driver prior to certain fixes being applied. In half-duplex SPI transactions, if the host was transmitting data while the co-processor queued a response, that frame would be silently discarded. When this discarded frame happens to be the first fragment of a fragmented response, the driver incorrectly treats the subsequent fragments as new, independent frames. Because these later fragments contain valid per-fragment headers and checksums, they pass standard validation checks despite being misinterpreted as standalone messages. This allows an attacker to inject raw protobuf continuation bytes into the parsing stream by influencing the size and content of legitimate control responses, such as AP scan lists which grow based on the number and SSID length of nearby access points. An unauthenticated attacker within radio range can thus manipulate these parameters to trigger the out-of-bounds read condition during frame processing.
The primary impact of this vulnerability is a denial of service rather than information disclosure or remote code execution. The act of reading past the end of the RAM region typically causes a hardware fault that crashes the device. Furthermore, because the driver configuration enables nanopb dynamic memory allocation via CONFIG_NANOPB_ENABLE_MALLOC, the garbage length prefixes read from out-of-bounds locations can trigger unintended heap allocations, further destabilizing system resources. Although the decoded data itself rarely reaches the application layer due to immediate failures in pb_decode when processing misaligned protobuf continuation bytes, and subsequent validation steps like esp_hosted_response requiring exact message ID matches would likely reject any partially valid output, the side effects of the memory corruption are sufficient to cause a crash. The attacker influences response sizes but not the structural integrity required for successful decoding, ensuring that exploitation results in system instability rather than data exfiltration.
The denial of service is made permanent by two additional defects within the same receive path that prevent automatic recovery without a manual reboot. First, the fragment reassembly guard was incorrectly sized using ESP_FRAME_SIZE instead of ESP_FRAME_MAX_PAYLOAD. When this incorrect limit is tripped, the driver returns from the sole receiver thread rather than dropping the malformed frame, effectively halting all incoming packet processing. Second, unhandled control events are queued into a message queue with only eight entries using K_FOREVER blocking semantics. Since no process drains these specific event queues, any accumulation of such messages will block the receiver thread indefinitely. Combined with the absence of a watchdog timer or automatic restart mechanism for Wi-Fi reception, either condition results in a permanent loss of connectivity until the device is physically rebooted.
From a security standards perspective, this vulnerability aligns with CWE-125 Out-of-bounds Read and CWE-787 Out-of-bounds Write if heap corruption occurs due to malformed length fields leading to excessive allocation attempts. The exploitation technique involves manipulating network protocol parsing logic, which relates to ATT&CK techniques involving input validation bypasses in embedded systems firmware. Mitigation strategies must focus on rigorous bounds checking before passing TLV data lengths to decoding functions. Developers should ensure that all frame fragments are validated against expected maximum payload sizes and that reassembly buffers are correctly sized relative to the protocol specifications rather than arbitrary constants. Additionally, implementing proper error handling for queue overflows and integrating watchdog timers can prevent permanent service degradation caused by single-point failures in the driver's event processing loop.