{ "schema_version": "1.6.1", "id": "RPI-CVE-2026-93165", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2026-93165" ], "published": "2026-09-17T16:10:40Z", "summary": "platform/chrome: sensorhub: Fix memory overread in ring handler", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nplatform/chrome: sensorhub: Fix memory overread in ring handler\n\n`max_response` and `sensor_num` are read from different EC commands:\n\n- `max_response` is from cros_ec_get_proto_info().\n ec_dev->max_response = info->max_response_packet_size -\n sizeof(struct ec_host_response);\n\n- `sensor_num` is from cros_ec_get_sensor_count().\n sensor_num = cros_ec_get_sensor_count(ec);\n\nWith a malfunctioning EC firmware, it is possible that the `msg->insize`\n(i.e., `fifo_info_length` in the context) could be clamped in\ncros_ec_cmd_xfer() because `msg->insize` is greater than `max_response`.\n\n int fifo_info_length =\n sizeof(struct ec_response_motion_sense_fifo_info) +\n sizeof(u16) * sensorhub->sensor_num;\n\nThis means the number of read bytes could be less than expected. As a\nresult, the subsequent memcpy() in cros_ec_sensorhub_ring_handler()\noverreads the `resp->fifo_info` buffer.\n\nCheck the return value of cros_ec_cmd_xfer_status() and abort if the\nnumber of bytes read does not match the expected length.", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H" } ], "affected": [ { "package": { "ecosystem": "Raspberry Pi OS:12", "name": "linux" }, "versions": [ "1:6.1.47-1+rpt4" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.1.0-rpi3-rpi-2712", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v6", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7l", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v8", "binary_version": "1:6.1.47-1+rpt4" } ] }, "database_specific": { "per_version": { "1:6.1.47-1+rpt4": { "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e", "upstream_version": "6.1.47", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.188", "compiled_filter": false } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2026-93165" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/98604cc8fd2578442f49cd113481e8fc83bc0ad3" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/86bcfab7dff6f0a61cbe0660e5176e907353141b" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/7e901aaf95828364b05a2120a1bea1a1669bdc9a" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/7780d93ae28f31fe517417c9451255315d1ad584" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/ee0403520cdbcf87e853df9aaa9b518a0684ed38" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/847a5ba0ac75f609e3f88da905251f7a76179145" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/6268f46d83875d294d75b68b97a5b79953744598" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/d1ceb2b2324717fa30b44d56ef0c52813e239569" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-09-18T17:55:42Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 7.7, "cvss_v3_severity": "High", "scenario": "AV:L - The MOTIONSENSE_CMD_FIFO_INFO bytes that cros_ec_sensorhub_ring_handler() memcpy()s, plus the mismatched max_response (cros_ec_get_proto_info) and sensor_num (MOTIONSENSE_CMD_DUMP via cros_ec_get_sensor_count), arrive from the on-board Chrome EC through cros_ec_irq_thread \u2192 event_notifier \u2192 cros_ec_sensorhub_event, not from a network protocol or pluggable USB device.\nAC:L - A compromised EC sets dump.sensor_count and GET_PROTOCOL_INFO max_response_packet_size so fifo_info_length exceeds max_response, then sends EC_MKBP_EVENT_SENSOR_FIFO with total_lost != 0. cros_ec_cmd_xfer() clamps insize and the memcpy of fifo_info_length then runs deterministically with no race.\nPR:N - cros_ec_sensorhub_ring_handler() runs from the MKBP IRQ notifier with no capable() or credential check. cros_ec_sensorhub_ring_add() calls cros_ec_sensorhub_ring_fifo_enable(true) at probe, so compromised EC firmware can trigger the FIFO_INFO overread without a host account.\nUI:N - FIFO interrupts are armed in cros_ec_sensorhub_ring_add() during driver probe; the EC_MKBP_EVENT_SENSOR_FIFO IRQ alone reaches the memcpy. No victim must open an IIO device, the cros_ec chardev, or take any other action.\nS:U - The overread is of the host kernel heap object allocated for sensorhub->msg in cros_ec_sensorhub_probe(); impact stays in the same kernel that runs the sensorhub driver, not a VM, IOMMU, or sandbox boundary.\nC:H - After clamping, memcpy(fifo_info, &resp->fifo_info, fifo_info_length) reads past the max_response-sized msg->data allocation into adjacent slab. With dump.sensor_count up to 255 that is hundreds of bytes of kernel heap, and fifo_info->lost[] is later printed in the \"Sensor %d: lost: %d\" warning, not a few-byte leak.\nI:N - fifo_info is allocated fifo_info_length bytes in cros_ec_sensorhub_ring_allocate(), so the memcpy destination is in-bounds. fifo_info->count/size are then checked against fifo_size before MOTIONSENSE_CMD_FIFO_READ; this is an overread only, with no OOB write or control-flow hijack.\nA:H - memcpy() of fifo_info_length past the probe kmalloc (sizeof(cros_ec_command)+max_response) can walk off the slab into unmapped or poisoned memory and oops. A malicious EC can report a tiny max_response and large sensor_count to make that overread hundreds of bytes from a small object." } } }