CVE-2026-89621: HID: mcp2221: validate report size in mcp2221_raw_event()
In the Linux kernel, the following vulnerability has been resolved:
HID: mcp2221: validate report size in mcp2221rawevent()
mcp2221rawevent() never validates the size of incoming HID reports. In the MCP2221I2CGETDATA path it trusts the device-supplied data[3] as the copy length without checking that 4 + data[3] bytes actually exist in the received report. A malicious or misbehaving USB device can send a short report with a large data[3], causing the memcpy to read past the valid report data in the HID transfer buffer and leak uninitialized kernel memory back to userspace through the I2C/SMBus read path.
Add a minimum size check at entry and validate that the source range fits within the received report before the copy.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Update the mcp2221 driver so mcp2221_raw_event() validates the size of incoming HID reports. In the MCP2221_I2C_GET_DATA path, use a bounds check to ensure that 4 + data[3] bytes actually exist in the received HID report before copying (avoid memcpy reading past the valid report data into the HID transfer buffer).
Linux kernel mcp2221 driver (mcp2221_raw_event()) validate incoming HID report size before memcpy in MCP2221_I2C_GET_DATA path = implemented: ensure 4 + data[3] bytes fit within received report
Event History
Frequently Asked Questions
Who is exposed to this issue?
Systems using the Linux MCP2221 HID driver are exposed when they communicate with a malicious or malfunctioning MCP2221 USB device that provides crafted short HID reports.
What does an attacker need to exploit it?
An attacker needs control of, or the ability to present, a USB device that sends a short report with a large length value in data[3]. The vulnerable path is reached during MCP2221 I2C/SMBus data reads.
What is the impact of successful exploitation?
The driver can read beyond the valid HID report data and return uninitialized kernel memory to userspace through the I2C/SMBus read path.
What change addresses the issue?
The fix adds an entry minimum-size check and verifies that 4 plus the device-supplied length fits within the received report before copying data.