diff options
| author | Tzung-Bi Shih <tzungbi@kernel.org> | 2026-07-02 08:27:45 +0000 |
|---|---|---|
| committer | Tzung-Bi Shih <tzungbi@kernel.org> | 2026-07-03 03:29:07 +0000 |
| commit | d1ceb2b2324717fa30b44d56ef0c52813e239569 (patch) | |
| tree | 45a927c9a9ff99f09cf8546b43e014773fafd620 /io_uring/uring_cmd.h | |
| parent | a0a8cd9fc9c48b95095bcec4b146f7a99486f58e (diff) | |
| download | linux-next-d1ceb2b2324717fa30b44d56ef0c52813e239569.tar.gz linux-next-d1ceb2b2324717fa30b44d56ef0c52813e239569.zip | |
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.
Fixes: 145d59baff59 ("platform/chrome: cros_ec_sensorhub: Add FIFO support")
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Link: https://lore.kernel.org/r/20260702082745.1014968-1-tzungbi@kernel.org
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
Diffstat (limited to 'io_uring/uring_cmd.h')
0 files changed, 0 insertions, 0 deletions
