Linux Kernel CVE-2026-93165

Requires a ChromeOS Embedded Controller (cros_ec) whose firmware returns inconsistent values - specifically a max_response_packet_size that causes msg->insize (fifo_info_length = sizeof(ec_response_motion_sense_fifo_info) + sizeof(u16) * sensor_num) to be clamped in cros_ec_cmd_xfer(), so fewer bytes are returned than the ring handler expects. This is only reachable on systems using the cros_ec_sensorhub driver (Chromebooks / ChromeOS devices with EC-attached motion sensors). LIMITING FACTORS: the trigger is a malfunctioning or tampered EC firmware rather than a userspace-controllable input, so practical exploitation presupposes firmware-level control or a genuinely defective EC; the affected code path must be built and the sensorhub FIFO in use.

The vendor CVSS of 7.7 (AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H) overstates real-world risk. This is a kernel driver-hardening fix: cros_ec_sensorhub_ring_handler() memcpy's from resp->fifo_info using an expected length, but when EC firmware misbehaves, cros_ec_cmd_xfer() clamps msg->insize (because it exceeds max_response), so fewer bytes are read than the handler assumes - causing an over-read of the fifo_info buffer. The precondition is a MALFUNCTIONING (or maliciously reflashed) EC firmware that returns an inconsistent max_response vs. sensor_num - not an ordinary local/remote attacker input path. That makes PR:N and AC:L unrealistic: controlling EC firmware responses is a firmware/physical-level capability, not unauthenticated userspace access. The impact is an over-read (bounded information disclosure and/or crash), not the arbitrary code-worthy C:H the vendor assigns. No EPSS, KEV, or POC data is present. Net: a genuine but low-priority hardening fix, not a widely exploitable vulnerability. NOTE: CVSS marks AV:L/PR:N yet the actual trigger requires control over EC firmware behavior - verify the intended threat model with the vendor.

On a Chromebook or ChromeOS-based device with a malfunctioning or tampered embedded controller (EC), the EC returns a max_response smaller than the fifo_info length implied by its reported sensor count. When the sensorhub ring handler processes a FIFO info response, the driver memcpy's more bytes than were actually read, over-reading adjacent kernel memory and leaking data into the sensor ring or crashing the kernel. No public exploit code is identified at time of analysis.