CVE-2026-89621

What it actually does

The Linux kernel HID driver for the Microchip MCP2221 USB-to-I2C/UART bridge fails to validate incoming HID report length in mcp2221_raw_event() before using a device-supplied length byte in the MCP2221_I2C_GET_DATA path. A short report with an inflated length field causes memcpy to read past the valid HID transfer buffer, exposing uninitialized kernel heap or transfer-buffer contents. The leaked bytes are returned to userspace through the I2C/SMBus read interface. This is an out-of-bounds read / kernel information disclosure, not a write primitive or remote code execution. Exploitation requires a USB HID device that the mcp2221 driver binds to (malicious, compromised, or malfunctioning hardware), so it is a local/adjacent physical-USB attack, not a network-facing remote flaw.

Why it matters to the business

Systems that load the mcp2221 HID driver and accept untrusted USB devices can have kernel memory contents disclosed to a local process or to whoever controls the USB device and a cooperating userspace I2C/SMBus client. Leaked kernel memory may include residual secrets, pointers useful for defeating KASLR, or other sensitive data, which can assist follow-on local privilege escalation. There is no CISA KEV listing, no reported ransomware use, and no public exploit maturity as of this writing (published about 38 days ago), so mass opportunistic exploitation is not indicated. Operational risk is highest for kiosks, industrial/embedded Linux, lab benches, VMs with USB passthrough, and any fleet that allows arbitrary USB HID devices. Downstream impact is limited to Linux kernels that include this driver rather than a broad application-library ecosystem.

How an attack unfolds

An attacker who can attach USB hardware (physically, via a compromised hub, or through USB passthrough to a guest) presents a device the kernel binds to the mcp2221 HID driver. The device emits HID interrupt/raw reports that are shorter than the driver assumes, while advertising a large copy length in the untrusted length field used by the I2C GET_DATA handling. The kernel copies past the received report into adjacent uninitialized buffer memory and surfaces that data on a subsequent userspace I2C/SMBus read. No named threat actors or in-the-wild campaigns are associated with this issue. Because the bug is an information leak rather than a write, it is typically used as a local reconnaissance step, not as a standalone ransomware or worm primitive.

How to fix it

Apply the Linux kernel fix that adds a minimum HID report size check on entry to mcp2221_raw_event() and verifies that the source range (4 + device-supplied length) fits entirely within the received report before memcpy. Upgrade to a distribution kernel that includes that HID mcp2221 validation patch; exact version strings were not supplied with this record, so use vendor/security advisories and git history for hid-mcp2221 / mcp2221_raw_event. If a patched kernel cannot be deployed immediately, unload or blacklist the mcp2221 HID driver on hosts that do not need MCP2221 adapters, restrict USB HID device attachment (USB authorization, udev rules, or physical port control), and avoid USB passthrough of untrusted devices into high-value guests. Do not rely on userspace I2C consumers to sanitize kernel-returned data as a primary control.

How to confirm the fix worked

Confirm the running kernel includes the mcp2221_raw_event report-size validation (minimum length check and bounds check of 4 + length against the received report size) via distribution changelog, kernel config/module version, or inspection of the hid-mcp2221 source used to build the image. Verify hosts that do not require the adapter have the module blacklisted and that it is not loaded (lsmod / /proc/modules). After patching, regression-test legitimate MCP2221 I2C/SMBus reads with in-spec HID report sizes only; do not use malformed USB gadgets or crafted short reports as a validation method. Inventory USB HID devices (vendor/product IDs associated with MCP2221-class adapters) and confirm untrusted USB is blocked on production systems.

Typical attack path

1. Gain the ability to attach or emulate a USB HID device that the mcp2221 driver will claim (physical port, malicious accessory, or USB passthrough).
2. Cause the kernel to bind hid-mcp2221 and open the I2C/SMBus path that processes MCP2221 GET_DATA reports.
3. Send undersized HID reports whose device-controlled length field exceeds the actual received payload.
4. Issue userspace I2C/SMBus reads so the out-of-bounds copy is returned as I2C data.
5. Inspect the returned buffer for kernel pointers or residual secrets and, if useful, combine with a separate local privilege-escalation bug.

How to detect it

There is no public exploit and no associated threat-actor playbook, so confirmed in-the-wild exploitation will be rare and noisy indicators are limited. Hunt for unexpected binding of the mcp2221 HID driver, USB attach of MCP2221-class devices on hosts that should not have them, and userspace processes performing I2C/SMBus reads against that adapter around the same time. Review kernel logs (dmesg, journal, kern.log) for hid-mcp2221 probe/bind messages and USB enumeration of Microchip HID adapters. Because this is an information leak, successful abuse typically does not oops or panic; absence of a crash does not mean the bug was unused. If USB monitoring is available (audit of device authorize, udev, or USBGuard), alert on first-seen MCP2221-like devices. Memory-leak abuse will not leave a distinctive payload file; correlate USB attach with subsequent I2C character-device or i2c-dev activity.

• mcp2221
• hid-mcp2221
• mcp2221_raw_event
• MCP2221_I2C_GET_DATA
• idVendor=04d8
• idProduct=00dd
• usb 04d8:00dd
• Microchip Technology Inc. MCP2221

What your security team should do

• Prioritize kernel updates on Linux hosts that load hid-mcp2221 or that allow untrusted USB HID devices, even though this CVE is not in KEV and has no known public exploit.
• Blacklist or unload mcp2221 on systems that do not use Microchip MCP2221 USB-I2C/UART adapters.
• Enforce USB device allowlisting / USB authorization so only expected HID adapters can bind.
• Treat USB passthrough into VMs and CI runners as in-scope for this class of HID parsing bugs.
• Track distribution security trackers for the exact kernel package that contains the mcp2221_raw_event bounds checks and confirm rollout.
• Do not invest in exploit development or malformed-report test harnesses; validate by patch presence and driver load state only.