Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.7",
  "pubDate": "2026-10-09T08:16:54.817Z",
  "pubdate": "2026-10-09T08:16:54.817Z",
  "executiveSummary": "This vulnerability is an out-of-bounds (OOB) memory access and race condition in the ITE IT8xxx2 SHI (SPI Host Interface) host-command backend.\nThe flaw stems from an unsafe buffer handling process where host-command headers are written to a shared buffer before validation, compounded by an interrupt handler that allows state transitions regardless of the command processing status.\nThe vulnerability allows a malicious host processor to trigger an out-of-bounds read or memory corruption by racing the Embedded Controller (EC) host-command thread.\nSuccessful exploitation results in the disclosure of sensitive internal EC memory or a system fault, potentially leading to privilege escalation or denial-of-service.\nExploitation requires physical access to the SPI bus or control over the host OS to manipulate timing and trigger the race condition.\nThe risk is significant due to the nature of the EC's role in system security; compromised ECs can circumvent host-level security mechanisms.",
  "technicalDetails": "The root cause is a race condition between the interrupt handler responsible for processing incoming SPI traffic and the host-command thread responsible for executing registered command handlers. Specifically, the file 'subsys/mgmt/ec_host_cmd/backends/ec_host_cmd_backend_shi_ite.c' performs a direct copy of the 8-byte SPI Rx FIFO header into 'data->in_msg' prior to validating the protocol version or packet length.\nBecause the interrupt handler accepts 'chip-select' assertion and 'Rx-valid-length' (RVLI) interrupts regardless of the internal driver state, the EC may overwrite the shared 'in_msg' buffer with a new, malicious header while a previous command is still being processed. This effectively bypasses the 'verify_rx()' checks performed in 'subsys/mgmt/ec_host_cmd/ec_host_cmd_handler.c'.\nThe attack flow proceeds as follows: First, the host sends a valid request, causing the EC to enter a processing state. Second, the host immediately de-asserts chip select and initiates a second transaction, providing a forged header with 'data_len = 0xFFFF'. If the host wins the race—triggering the write of the forged header into 'in_msg' before the host-command thread consumes the 'data_len' field—the framework incorrectly trusts the attacker-supplied length.\nWhen the command handler executes, it receives a 65535-byte input length parameter for a buffer that is only 256 bytes in size. This leads to an out-of-bounds read of adjacent SRAM contents, which are subsequently echoed back to the host, or an out-of-bounds write that corrupts memory. Additionally, the race can be leveraged to swap 'cmd_id' and 'cmd_ver' fields after the validation phase, potentially causing the EC to execute arbitrary handler logic with attacker-controlled input.\nThe vulnerability is persistent, as the host controller can indefinitely retry the transaction until the timing race is won. While the fix introduces a local struct to sanitize headers before updating the shared buffer and restricts interrupt state handling, a residual race remains because the end-of-transaction interrupt still allows a state reset while the host-command thread owns the buffer, leaving the system susceptible to overwrites during command processing."
}