CVE-2026-89622

What it actually does

A write use-after-free in the Linux kernel HID driver for Microchip MCP2221 USB-to-I2C/SMBus adapters. mcp_i2c_smbus_read() stores the caller-supplied receive buffer in mcp->rxbuf for the transfer but does not clear that pointer when the transfer completes or times out. After the caller frees or reuses the buffer, a delayed or spurious MCP2221_I2C_GET_DATA HID report can cause mcp2221_raw_event() to memcpy device data into freed kernel memory, corrupting the heap. Local low-privileged access can therefore yield arbitrary kernel writes, privilege escalation, or a kernel panic (CVSS 7.8: C/I/A High).

Why it matters to the business

Linux hosts that attach MCP2221 USB-I2C/SMBus bridges—common on development boards, industrial controllers, and USB adapters—can be fully compromised by a local user, causing host takeover, data integrity loss, or unplanned outages. The flaw is not in CISA KEV, is not associated with ransomware, and has no known public exploit maturity about 38 days after publication, but the complete confidentiality, integrity, and availability impact still justifies prompt kernel patching on multi-user, shared, or kiosk Linux systems where untrusted local users or USB devices are present.

How an attack unfolds

An attacker with local, low-privileged access on a Linux system that has an MCP2221 HID device (or the hid-mcp2221 driver loaded) initiates or waits for an I2C/SMBus read so the driver stashes a pointer to the caller’s receive buffer. When that transfer finishes or times out, the caller frees the buffer while the driver still holds mcp->rxbuf. The attacker then causes or waits for a late or injected MCP2221_I2C_GET_DATA HID report; the raw-event path copies device data into the dangling buffer, corrupting kernel heap. That write use-after-free can be leveraged for local privilege escalation or to crash the kernel. No named threat actors or in-the-wild campaigns are associated with this issue, and exploit maturity is none.

How to fix it

Apply vendor or distribution Linux kernel updates that include the HID mcp2221 fix: all mcp_i2c_smbus_read() return paths must clear mcp->rxbuf and mcp->rxbuf_size so mcp2221_raw_event() rejects reports after the transfer ends. Prefer the latest stable kernel from your distro (or upstream) that contains this HID mcp2221 change. If a patch is not yet available, unload or blacklist hid-mcp2221 where the hardware is unused, restrict who can access HID/I2C interfaces, and limit untrusted local users and USB device attachment on affected hosts. Reboot into the patched kernel to load the fixed driver.

How to confirm the fix worked

Confirm the running kernel changelog or package notes mention the HID mcp2221 rxbuf-clear fix. On source trees, verify mcp_i2c_smbus_read() routes all exits through a single path that nulls mcp->rxbuf and mcp->rxbuf_size, and that mcp2221_raw_event() still guards on !mcp->rxbuf. After upgrade, reboot, check uname -r and that hid-mcp2221 matches the patched package, and exercise a normal I2C/SMBus read against an MCP2221 if hardware is present without kernel oops or KASAN reports. Inventory hosts with hid-mcp2221 loaded or MCP2221 USB IDs attached to find remaining exposure.

Typical attack path

1. Gain local unprivileged access on a Linux host with an MCP2221 device present or hid-mcp2221 loaded
2. Cause an I2C/SMBus read so the driver stores a receive-buffer pointer
3. Allow the transfer to complete or time out so the caller frees the buffer while the pointer remains
4. Induce or wait for a delayed or spurious MCP2221_I2C_GET_DATA HID report
5. Kernel memcpy into freed memory corrupts the heap
6. Abuse the resulting write use-after-free for local privilege escalation or denial of service

How to detect it

This is a local kernel write use-after-free with no public exploit, so evidence of prior abuse is most likely a kernel oops, panic, or KASAN slab-use-after-free whose stack mentions mcp2221_raw_event, mcp_i2c_smbus_read, or hid-mcp2221, possibly after I2C/SMBus timeouts or unusual HID traffic on an MCP2221. Review dmesg, journalctl -k, vmcore/kdump, pstore, and crash dumps around USB HID attach of MCP2221 devices; look for unexpected GET_DATA-style HID reports after a transfer has ended. Audit who had local access and whether untrusted USB devices were attached. Absent a crash or sanitizer report, successful silent exploitation may leave little besides unexplained privilege changes or kernel heap corruption symptoms.

• mcp2221_raw_event
• mcp_i2c_smbus_read
• hid-mcp2221
• MCP2221_I2C_GET_DATA
• KASAN: slab-use-after-free in mcp2221
• Oops:.*mcp2221
• usbhid.*mcp2221

What your security team should do

• Prioritize kernel updates on multi-user Linux hosts and any system with MCP2221 USB-I2C/SMBus adapters attached
• Inventory loaded hid-mcp2221 modules and MCP2221 USB devices; unload or blacklist the driver where the hardware is not required
• Restrict local logins and USB/HID device access until patched kernels are deployed
• Watch kernel logs and crash dumps for mcp2221/hid-mcp2221 oops, KASAN use-after-free, or panics; there is no KEV listing and no known exploit, but treat local heap corruption as high impact
• Track distro kernel advisories for this HID mcp2221 change and confirm post-reboot that the fixed driver is in use