CVE-2026-93165
High · 7.7CVSS
7.7
EPSS
0.2%
Published
Sep 17, 2026
CISA due date
—
Cloudanix analysis
A flaw in handling data from a device's internal controller could let the system read more memory than it should, risking exposure of private information or system instability.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Low
- Impact
- Data Exposure
- Component
- OS kernel
- Class
- Memory Corruption
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Memory overread occurs in the cros_ec_sensorhub_ring_handler when cros_ec_cmd_xfer clamps the returned bytes below the expected length derived from sensor_num and fifo_info_length, allowing memcpy to read past the resp->fifo_info buffer bounds.
Why it matters to the business
Systems using affected Chrome OS EC sensor hubs may experience kernel memory disclosure or crashes when the embedded controller returns inconsistent protocol data, increasing exposure of sensitive kernel contents and potential denial of service on affected devices.
How an attack unfolds
An attacker with the ability to supply or induce a malfunctioning EC firmware causes cros_ec_get_proto_info and cros_ec_get_sensor_count to report mismatched max_response and sensor_num values; subsequent cros_ec_cmd_xfer returns fewer bytes than fifo_info_length, and the ring handler memcpy then reads beyond the allocated response buffer.
How to fix it
Update to a kernel containing the fix that validates the return value of cros_ec_cmd_xfer_status against the expected length before the memcpy; apply the corrected platform/chrome sensorhub code.
How to confirm the fix worked
Confirm the patch is present by inspecting cros_ec_sensorhub_ring_handler for the added length check after cros_ec_cmd_xfer_status; test with an EC simulator that returns truncated FIFO info responses and verify no overread occurs.
Typical attack path
- Gain local access or control over EC firmware to induce malformed responses
- Trigger motion-sense FIFO info query via sensorhub ring handler
- Force cros_ec_cmd_xfer to clamp insize below expected length
- Execute memcpy that overreads resp->fifo_info buffer
- Observe leaked kernel memory or trigger kernel fault
How to detect it
Review kernel logs for sensorhub ring handler faults or unexpected short transfers from cros_ec_cmd_xfer; examine dmesg and audit logs around EC command failures for evidence of truncated motion sense FIFO responses.
What your security team should do
- Prioritize kernel updates on all Chrome OS and Linux devices using cros_ec sensorhub
- Monitor vendor advisories for backported fixes in supported LTS kernels
- Harden EC firmware integrity checks where possible to reduce malformed response risk
The record
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.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|