ims-pcu driver for IMS Passenger Control Unit hardware, and the upstream Linux fix was committed on April 8, 2026—four months before Microsoft’s public CVE entry appeared.For Windows administrators, there is no Microsoft KB to deploy, no Windows build to assess, and no indication that Windows 10, Windows 11, Windows Server, Hyper-V, or any Microsoft driver is affected. Microsoft’s entry identifies the CVE and repeats the Linux patch subject, but does not name an affected Microsoft product, release channel, or security update. The practical action belongs with Linux fleet owners and embedded-device vendors that enable the
ims-pcumodule.
The more consequential detail is that the upstream Linux maintainer did not consider the fix important enough for stable-kernel backporting. That means the systems most likely to remain exposed are not mainstream desktops, but older Linux appliances and specialized deployments that continue to run long-term or vendor-maintained kernels with this unusual USB driver enabled.
The vulnerable component is an IMS Passenger Control Unit driver
The affected code sits in
drivers/input/misc/ims-pcu.c, a Linux driver whose own module description calls it the “IMS Passenger Control Unit driver.” It is compiled only when the kernel is configured with
CONFIG_INPUT_IMS_PCU, a tristate option dependent on USB and the Linux LED class framework. In a modular build, the driver appears as
ims-pcu.
The device is not a generic USB keyboard, game controller, or common Windows peripheral. The source identifies particular USB hardware IDs from Microchip Technology, vendor ID
0x04d8, with product IDs
0x0082and
0x0083. The driver exposes button input, optional gamepad input, backlight control, firmware functions, and optical-finger-navigation support associated with the Passenger Control Unit hardware.
That narrow hardware scope materially limits exposure. A Linux host is not vulnerable merely because it has USB ports or uses the general Linux input subsystem. It must be running a kernel that contains the vulnerable code, have
CONFIG_INPUT_IMS_PCUenabled or the
ims-pcumodule available, and bind that driver to a matching device. An attacker would then need a malicious or compromised device capable of speaking the expected USB protocol.
Still, “specialized” does not mean harmless. USB trust boundaries are routinely weaker than network trust boundaries in industrial, transport, kiosk, lab, and field-service environments. A device that is physically legitimate but has been reflashed—or a malicious device made to impersonate the relevant USB identifiers—can reach a driver before ordinary user-space controls have an opportunity to inspect its traffic.
A malformed USB frame can corrupt kernel memory
The flaw is in
ims_pcu_process_data(), which reads incoming USB Request Block data one byte at a time and reconstructs protocol frames. Before the April fix, it appended incoming bytes to a fixed 128-byte
read_bufarray without checking whether the running
read_posindex had reached the array limit.
The upstream commit by Seungjin Bae explains the dangerous follow-on behavior:
read_posis stored immediately after
read_bufin the driver’s structure. A packet exceeding 128 bytes can overwrite that index, allowing subsequent writes to be directed beyond the intended buffer. When the driver later handles a response, it copies
read_posbytes into another fixed-size
cmd_buf, creating the heap-buffer overflow described by CVE-2026-64565.
The original patch analysis goes further than the short CVE title. It says crafted data can overwrite the completion object located after
cmd_buf; when the driver signals that command completion, the corrupted state can be used for control-flow hijacking. That is a kernel-memory corruption condition, not simply a crash or a rejected USB request.
The fixed code adds the missing boundary test before each write path to
read_buf, including the escaped-byte path in the parser. When a frame grows beyond the maximum, the driver logs a warning, throws away the frame, resets its parser state, and waits for the next valid start marker. The repair is small, but it closes the critical path: attacker-controlled input no longer advances into adjacent kernel memory.
The public CVE date hides an older upstream fix
Microsoft lists the CVE as published on August 9, 2026. The primary Linux kernel record places the upstream commit,
875115b82c295277b81b6dfee7debc725f44e854, on April 8, 2026. The patch had been discussed publicly even earlier: version two was posted to the Linux input mailing list on December 19, 2025.
This is not evidence that the vulnerability was fixed overnight as part of a Microsoft security release. The timeline is the reverse: the Linux community developed and merged the correction first, then the CVE was publicly indexed later through Microsoft’s Security Update Guide. Microsoft’s page is therefore a useful identifier record, but it is not the remediation source and should not be treated as a Patch Tuesday advisory.
The commit was merged through the input subsystem’s
input-for-v7.1-rc0branch. Linux users on kernels derived from that upstream line should verify whether their distributor incorporated the commit or an equivalent patch. The exact release number alone is not enough: enterprise distributions and embedded vendors frequently carry selected fixes on older version strings, while other products retain old driver code for years.
Microsoft’s listing also supplies no CVSS score, attack-vector analysis, known exploitation status, affected-version range, or remediation guidance. Those omissions matter more than usual because the driver’s real deployment footprint is exceptionally narrow and because the upstream discussion directly addressed whether a stable backport was warranted.
Stable-kernel users may not receive the correction
Greg Kroah-Hartman later asked why the merge had not been marked for stable inclusion. Dmitry Torokhov, the Linux input subsystem maintainer, responded that he did not believe it was worth doing: he characterized
ims-pcuas a driver for specialized hardware, said common distributions were unlikely to enable it, and noted that installations using it likely would not accept arbitrary devices.
That is a maintainer assessment of deployment likelihood, not a technical mitigation. The overflow condition exists wherever the pre-fix driver is built and can bind to the targeted hardware. The absence of a stable tag means administrators cannot assume a current Linux 6.x long-term-support kernel automatically contains the fix.
The discussion also revealed that the driver has received little functional maintenance. Torokhov noted that its only non-cleanup change had been made in 2014 and suggested that the driver might be removed from the kernel rather than carried indefinitely. Kroah-Hartman agreed to work on a removal after the next release candidate cycle.
That possible removal should not be mistaken for a patch. Removing a driver in a future upstream kernel protects only systems that adopt that future code and do not require the hardware. It does nothing for a deployed embedded image, appliance firmware, custom Android-derived kernel, or vendor distribution that keeps the existing
ims-pcu.csource.
What Linux fleet owners should check
Organizations with mixed Windows and Linux estates should route this CVE to the Linux platform or product-security owner, not to the Windows servicing team. The immediate triage question is whether the target system can load
ims-pcu, not whether it has installed the latest cumulative update.
A focused assessment should establish the following:
- Check the running kernel configuration for
CONFIG_INPUT_IMS_PCUand determine whetherims-pcuis built into the kernel, available as a module, or absent entirely. - Inspect loaded modules and attached USB hardware on Linux endpoints, appliances, and embedded systems that accept field-service or user-supplied USB devices.
- Ask the kernel, distribution, or appliance vendor whether it includes upstream commit
875115b82c295277b81b6dfee7debc725f44e854or has independently backported the bounds checks. - Where the driver is unnecessary, prevent it from loading or rebuild the kernel without
CONFIG_INPUT_IMS_PCU; that removes the vulnerable code path rather than relying on physical-device policy alone. - Where the hardware is required and no vendor update exists, restrict physical USB access and treat untrusted peripherals as a kernel-level risk.
The key conclusion is straightforward: CVE-2026-64565 does not create a Windows patching emergency. It does expose a remediation gap for the relatively small number of Linux systems still carrying and using the IMS Passenger Control Unit driver, particularly if they rely on stable or vendor kernels that never received the April upstream change.
References
- Primary source: MSRC
Published: August 9, 2026 at 8:41 AM UTC
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: android.googlesource.com
- Related coverage: android.googlesource.com
- Related coverage: sources.debian.org
- Related coverage: cateee.net
- Related coverage: nest-open-source.googlesource.com
- Related coverage: kernel.googlesource.com
- Related coverage: kernel.googlesource.com
- Related coverage: cocalc.com
