CVE-2026-93165 in Linux
Summary
by MITRE • 09/18/2026
In the Linux kernel, the following vulnerability has been resolved:
platform/chrome: sensorhub: Fix memory overread in ring handler
`max_response` and `sensor_num` are read from different EC commands:
- `max_response` is from cros_ec_get_proto_info(). ec_dev->max_response = info->max_response_packet_size - sizeof(struct ec_host_response);
- `sensor_num` is from cros_ec_get_sensor_count(). sensor_num = cros_ec_get_sensor_count(ec);
With a malfunctioning EC firmware, it is possible that the `msg->insize` (i.e., `fifo_info_length` in the context) could be clamped in cros_ec_cmd_xfer() because `msg->insize` is greater than `max_response`.
int fifo_info_length = sizeof(struct ec_response_motion_sense_fifo_info) + sizeof(u16) * sensorhub->sensor_num;
This means the number of read bytes could be less than expected. As a result, the subsequent memcpy() in cros_ec_sensorhub_ring_handler() overreads the `resp->fifo_info` buffer.
Check the return value of cros_ec_cmd_xfer_status() and abort if the number of bytes read does not match the expected length.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability identified as a memory overread in the Linux kernel's platform chrome sensorhub driver stems from an improper validation of input data lengths during command execution with embedded controller firmware. The core issue arises within the cros_ec_sensorhub_ring_handler function, which processes motion sense FIFO information retrieved from the hardware. Specifically, the code calculates an expected buffer size for fifo_info based on a fixed structure size plus a variable component derived from sensor_num. This sensor_num value is obtained via the cros_ec_get_sensor_count routine, while max_response, representing the maximum packet size supported by the embedded controller protocol, is determined separately through cros_ec_get_proto_info. These two values originate from distinct hardware queries and are not inherently synchronized or validated against each other in a way that guarantees consistency under all firmware states.
When interacting with the embedded controller via cros_ec_cmd_xfer_status, the kernel attempts to read data into a buffer sized according to the calculated fifo_info_length. However, if the embedded controller's firmware is malfunctioning or behaves unexpectedly, it may return less data than requested because msg->insize exceeds max_response. In such scenarios, the transfer function clamps the amount of actual data received to fit within the protocol limits defined by max_response. Consequently, the number of bytes actually written into the resp->fifo_info buffer becomes smaller than the fifo_info_length previously calculated based on sensor_num. This discrepancy creates a critical inconsistency where the logical expectation of data volume does not match the physical reality of what was transferred from the hardware device.
The direct operational impact occurs during the subsequent memcpy operation within cros_ec_sensorhub_ring_handler. Because the code assumes that the buffer contains exactly fifo_info_length bytes, it proceeds to copy or process this full amount regardless of how many bytes were actually populated by the transfer function. Since the actual data is shorter due to the clamping effect described above, the memory access extends beyond the bounds of the allocated resp->fifo_info buffer. This constitutes a classic out-of-bounds read vulnerability, allowing for a potential information leak where sensitive kernel memory contents adjacent to the buffer are exposed to user space or processed incorrectly by downstream logic. Such overreads can lead to system instability, crashes, or in worst-case scenarios, exploitation vectors that leverage leaked memory data for further attacks.
From a classification perspective, this flaw aligns with CWE-126, which denotes Buffer Over-read, as the application reads beyond allocated boundaries due to incorrect size calculations and lack of bounds checking relative to actual input sizes. It also relates to CWE-20 regarding Improper Input Validation, specifically the failure to verify that received data matches expected dimensions before processing. In terms of adversarial tactics, this vulnerability could be leveraged within an ATT&CK framework context under techniques involving Data from Local System or potentially T1059 Command and Scripting Interpreter if combined with other exploits, though primarily it serves as a mechanism for information disclosure (T1005) by exposing kernel memory contents.
To mitigate this risk, the primary remediation involves rigorous validation of transfer results before utilizing the received data. Developers must check the return value of cros_ec_cmd_xfer_status and explicitly verify that the number of bytes read matches the expected length derived from sensor_num and structural constants. If there is a mismatch indicating truncation or incomplete transmission due to firmware limitations, the operation should be aborted immediately rather than proceeding with an invalid buffer state. This ensures that no out-of-bounds access occurs regardless of how the embedded controller responds. Additionally, implementing stricter checks on max_response relative to sensor_num during initialization could prevent such mismatches from arising in the first place, ensuring that protocol limits are respected throughout the lifecycle of the driver's interaction with the hardware firmware.