ZephyrProject Zephyr up to 4.4.x ITE IT8xxx2 SHI host-command backend ec_host_cmd_backend_shi_ite.c verify_rx data_len out-of-bounds

Summaryinfo

A vulnerability, which was classified as problematic, has been found in ZephyrProject Zephyr up to 4.4.x. Affected by this vulnerability is the function verify_rx of the file subsys/mgmt/ec_host_cmd/backends/ec_host_cmd_backend_shi_ite.c of the component ITE IT8xxx2 SHI host-command backend. The manipulation of the argument data_len leads to out-of-bounds. This vulnerability is referenced as CVE-2026-19571. The attack can only be performed from a local environment. No exploit is available. It is advisable to upgrade the affected component.

Detailsinfo

A vulnerability was found in ZephyrProject Zephyr up to 4.4.x. It has been rated as problematic. This issue affects the function verify_rx of the file subsys/mgmt/ec_host_cmd/backends/ec_host_cmd_backend_shi_ite.c of the component ITE IT8xxx2 SHI host-command backend. The manipulation of the argument data_len with an unknown input leads to a out-of-bounds vulnerability. Using CWE to declare the problem leads to CWE-125. The product reads data past the end, or before the beginning, of the intended buffer. Impacted is confidentiality, integrity, and availability. The summary by CVE is:

The ITE IT8xxx2 SHI host-command backend (subsys/mgmt/ec_host_cmd/backends/ec_host_cmd_backend_shi_ite.c) copied the 8-byte host-command request header from the SPI Rx FIFO directly into the shared receive buffer data->in_msg and only afterwards checked the protocol version and the derived packet length. The interrupt handler also accepted a chip-select assertion and an Rx-valid-length (RVLI) interrupt in any driver state other than SHI_STATE_DISABLED, so a new header could be parsed while the host-command thread was still processing the previous request out of the very same buffer. The host processor is the SPI controller and drives both chip select and the clock. After sending a well-formed request it can immediately de-assert chip select — which returns the driver to the ready state and re-enables the FIFO — and start a second transaction carrying a header with data_len = 0xFFFF. Those eight bytes are written into in_msg before the oversized length is rejected, so they land in a buffer whose contents verify_rx() in subsys/mgmt/ec_host_cmd/ec_host_cmd_handler.c has already validated. If this lands in the window before the host-command thread executes args.input_buf_size = rx_header->data_len, the framework hands the registered command handler a 65535-byte input length over a 256-byte buffer. The result is an out-of-bounds read of up to roughly 64 KiB beyond the request buffer: command handlers that copy or echo input_buf_size bytes disclose adjacent embedded-controller memory back to the host or overflow the response buffer, and a read past the end of SRAM faults the controller. The same race also allows cmd_id and cmd_ver to be swapped after checksum verification and after handler lookup. Exploitation requires the ability to drive the inter-processor SHI bus (a compromised host OS or physical access to the SPI lines) and winning a timing race, which the SPI controller can retry indefinitely. The fix parses the header into a local struct ec_host_cmd_request_header and copies it into in_msg only after the length has been bounded by sizeof(data->in_msg), and ignores chip-select and RVLI interrupts outside SHI_STATE_READY_TO_RECV/SHI_STATE_RECEIVING. A residual, bounded race remains: an end-of-transaction interrupt still resets the state to ready while the host-command thread owns the buffer, so a valid second request can still overwrite the in-flight request's contents, unlike the NPCX backend which parks in SHI_STATE_CNL_RESP_NOT_RDY while the buffer is in use.

The advisory is shared at github.com. The identification of this vulnerability is CVE-2026-19571 since 08/11/2026. The exploitation is known to be easy. An attack has to be approached locally. Technical details are known, but no exploit is available.

Upgrading to version 4.5.0 eliminates this vulnerability. Applying the patch 0636e65c825e810ad97f154606365870152d402f is able to eliminate this problem. The best possible mitigation is suggested to be upgrading to the latest version.

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Productinfo

Type

• Project Management Software

Vendor

• ZephyrProject

Name

• Zephyr

Version

• 4.0
• 4.1
• 4.2
• 4.3
• 4.4

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Discussion