CVE-2026-89623

What it actually does

A use-after-free race in the Linux kernel HID driver for Microchip MCP2221 devices allows incoming HID reports to be processed while hardware is being torn down during probe failure or device removal, because I/O is not quiesced before hid_hw_stop. That can corrupt kernel memory and typically presents as an oops/panic; a carefully shaped race could yield arbitrary kernel-memory access.

Why it matters to the business

Hosts that attach MCP2221 USB-to-I2C/UART adapters (common in embedded, industrial, and lab setups) can suffer unexpected kernel crashes and downtime, and a successful local or physical-USB exploit could fully compromise the machine. Thirty-eight days after publication there is no CISA KEV listing, no ransomware association, and no public exploit maturity, so widespread exploitation risk is currently low; urgency is highest for fleets that load hid-mcp2221 or allow untrusted USB devices.

How an attack unfolds

An attacker who can bind a USB HID device to the mcp2221 driver, or who can force probe failure or unplug of a genuine adapter while reports are in flight, races HID input against driver teardown. If a report is handled after the HID device object is being freed, the kernel dereferences freed memory. The usual outcome is a denial-of-service crash; with additional local control the use-after-free could be turned into privilege escalation. No named threat actors or in-the-wild campaigns are tied to this issue, and exploit maturity is none.

How to fix it

Install a Linux kernel that includes the HID mcp2221 fix: mcp2221_hid_unregister() must call hid_device_io_stop() at the start of the devm cleanup path, gated on io_started so probe-failure balancing is preserved without a spurious warning on normal removal. Use the distribution or vendor kernel package that backports this change. Exact upstream package versions were not supplied with this record, so follow distro security advisories for the hid-mcp2221 teardown patch. Until patched, restrict untrusted USB (USB authorization, physical port control, lockdown) and avoid hot-removal of MCP2221 adapters under load.

How to confirm the fix worked

Confirm the running kernel changelog or source contains the io_started-guarded hid_device_io_stop() in mcp2221_hid_unregister. Check uname -r and vendor kernel errata for this fix; lsmod/sysfs can show whether hid-mcp2221 is loaded. Hosts that never load this driver and never attach MCP2221 hardware are not exposed. After patching, normal unplug should remain silent (no “io already stopped” warning), and probe-failure or removal under I/O should no longer race reports against hid_hw_stop.

Typical attack path

1. Obtain local access or the ability to attach or impersonate a USB HID device that binds to the mcp2221 driver.
2. Cause the driver to start I/O (successful or partial probe).
3. Trigger probe failure or device removal while HID reports are still arriving.
4. Win the race so a report is handled after teardown has begun, hitting the use-after-free.
5. Cause a kernel crash for denial of service, or attempt to convert the memory corruption into elevated privileges.

How to detect it

Search kernel logs (dmesg, journalctl -k, /var/log/kern.log, pstore/oops collectors) around USB bind/unbind of MCP2221 devices for oops, panic, use-after-free, or slab errors whose call traces mention mcp2221, mcp2221_hid_unregister, hid_hw_stop, or hid_device_io paths. Correlate with bursts of USB disconnect/reconnect and unexpected unbind of hid-mcp2221. There are no public in-the-wild exploit signatures; treat driver crashes during removal or failed probe as possible exploitation or as confirmation the race fired. Capture vmcore if an oops occurs for later root-cause.

• mcp2221_hid_unregister
• hid-mcp2221
• mcp2221
• hid_hw_stop
• io already stopped
• BUG: kernel NULL pointer dereference
• Unable to handle kernel paging request
• use-after-free
• idVendor=04d8 idProduct=00dd
• hid-mcp2221.ko

What your security team should do

• Inventory systems that load hid-mcp2221 or have MCP2221 USB devices attached and prioritize those for kernel updates.
• Deploy the vendor/distro kernel that contains the mcp2221 I/O-quiesce fix; do not wait for a KEV listing.
• Until patched, enforce USB allowlisting or authorization on servers, kiosks, and unattended hosts.
• Watch kernel logs for mcp2221-related oopses around USB attach/detach as a stopgap.
• Treat this as lower urgency than actively exploited kernel bugs given no KEV, no ransomware use, and no public exploits, but do not defer patching on USB-exposed fleets.