CVE-2026-64565

What it actually does

This is a Linux kernel memory-corruption flaw in the ims-pcu input driver. The vulnerable parser processes USB URB data without properly bounding the read_pos index against IMS_PCU_BUF_SIZE. A malicious USB device can send an oversized packet, cause read_pos to advance beyond the receive buffer, overwrite adjacent heap fields including read_pos itself, and later influence a copy into cmd_buf. The described corruption can reach cmd_done.wait.head and may allow kernel control-flow hijack when complete(&pcu->cmd_done) is called. Practical outcomes include kernel crash, denial of service, and potentially arbitrary code execution in kernel context depending on kernel configuration, mitigations, and exploit reliability.

Why it matters to the business

Successful exploitation can destabilize or fully compromise Linux systems that use the affected ims-pcu driver and accept input from a malicious or compromised USB device. Because exploitation requires a hostile USB device or equivalent control of USB traffic, broad internet-scale exposure is unlikely; however, the consequence on exposed workstations, embedded devices, kiosks, lab systems, or operational technology endpoints can be severe, including outages, device compromise, or bypass of host security controls. The issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, has no reported public exploit maturity, and has a low EPSS score, so remediation should be risk-prioritized but still tracked through normal kernel patch management.

How an attack unfolds

An attacker first needs a path to present a malicious USB device to a vulnerable Linux system, such as physical access, supply-chain insertion of a rogue peripheral, an evil-maid scenario, or compromise of a USB-capable device connected to the host. When the ims-pcu driver binds to the device and begins handling incoming URB data, the malicious device sends a packet larger than the driver’s expected buffer. Because the vulnerable code does not stop read_pos from exceeding IMS_PCU_BUF_SIZE, parsing continues past the end of read_buf and corrupts adjacent heap memory. By overwriting read_pos and shaping subsequent packet contents, the attacker can influence a later copy into cmd_buf. The vulnerability description indicates that corruption can target cmd_done.wait.head, causing the kernel completion path to dereference attacker-controlled data and potentially redirect control flow. Failed attempts are likely to produce kernel warnings, KASAN reports, oopses, USB/input driver errors, or system crashes.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the ims-pcu bounds-checking issue in ims_pcu_process_data(). Because no affected product list or exact fixed package versions were provided, use the kernel versions and advisories from the relevant Linux distribution, appliance vendor, or kernel maintenance branch. Where immediate patching is not possible, reduce exposure by disabling or blacklisting the ims-pcu driver if it is not required, restricting physical USB access, blocking untrusted USB peripherals through device-control tooling, and enforcing endpoint policies that limit newly attached USB input devices. For high-assurance environments, pair kernel updates with secure boot, kernel lockdown, IOMMU/USB authorization policies, and operational controls for removable devices.

How to confirm the fix worked

Confirm that systems are running a kernel build from the vendor branch that contains the ims-pcu bounds-check fix. Verify whether the ims-pcu driver is present or loaded using standard Linux module and kernel configuration checks, such as reviewing loaded modules, kernel config, and driver files. If the driver is not needed, confirm it is not loadable or is denied by module blacklist/device policy. Validate patch deployment by comparing installed kernel package versions against vendor advisories and rebooting into the patched kernel. For exposure validation, check whether systems accept USB peripherals and whether hardware inventory or endpoint telemetry shows devices binding to the ims-pcu driver. Avoid validating with malicious oversized USB packets on production systems, as proof-of-concept testing may crash the kernel.

Typical attack path

1. Attacker obtains the ability to connect or emulate a malicious USB device to a vulnerable Linux system.
2. The Linux kernel enumerates the device and binds it to the ims-pcu input driver.
3. The malicious device sends crafted URB data with a packet larger than IMS_PCU_BUF_SIZE.
4. ims_pcu_process_data() increments read_pos beyond the receive buffer and corrupts adjacent heap memory.
5. The attacker manipulates read_pos and packet contents so ims_pcu_handle_response() copies attacker-controlled data into sensitive heap structures near cmd_buf.
6. The corrupted cmd_done.wait.head structure is used during complete(&pcu->cmd_done), creating a possible kernel control-flow hijack or crash.
7. The attacker achieves denial of service or, if exploitation is reliable against the target kernel and mitigations, code execution with kernel privileges.

How to detect it

To assess prior exploitation, review kernel logs, system journals, crash dumps, endpoint telemetry, and USB device inventory for suspicious USB enumeration followed by ims-pcu driver activity, memory-corruption reports, or sudden kernel crashes. Useful sources include journalctl kernel logs, /var/log/kern.log, /var/log/messages, dmesg archives, kdump/vmcore records, audit logs for module loading, EDR telemetry for USB device insertion, and device-control platform logs. Look for KASAN, slab, heap, general protection fault, kernel oops, panic, or hung-task messages that reference ims_pcu_process_data(), ims_pcu_handle_response(), complete(), cmd_done, URB processing, or the ims-pcu driver. Correlate suspicious events with physical access records, newly attached USB devices, unexpected vendor/product IDs, repeated USB disconnect/reconnect cycles, or crashes occurring immediately after peripheral insertion. Because exploitation may only leave a crash or memory-corruption artifact, absence of logs does not fully rule out exploitation, especially if kernel crash dumps were not collected.

• ims-pcu
• ims_pcu
• ims_pcu_process_data
• ims_pcu_handle_response
• heap-buffer-overflow in ims_pcu_process_data()
• KASAN: slab-out-of-bounds
• KASAN: out-of-bounds
• KASAN: use-after-free
• BUG: kernel NULL pointer dereference
• general protection fault
• kernel BUG at
• Oops:
• Kernel panic - not syncing
• URB
• cmd_done.wait.head
• complete(&pcu->cmd_done)
• read_pos
• IMS_PCU_BUF_SIZE

What your security team should do

• Inventory Linux systems where the ims-pcu driver is present, loaded, or relevant to attached input/USB hardware.
• Prioritize patching systems with physical USB exposure, kiosk or public-access placement, shared workstations, embedded deployments, or sensitive operational roles.
• Update affected Linux kernels through the appropriate distribution or vendor channel and ensure systems reboot into the patched kernel.
• If the driver is unnecessary, blacklist or disable ims-pcu and enforce USB device-control policies to prevent untrusted peripherals from binding to kernel drivers.
• Review endpoint and kernel logs for recent USB enumeration events, ims-pcu activity, KASAN reports, kernel oopses, or unexplained crashes following USB device attachment.
• Apply stricter physical security and removable-device handling procedures for high-value Linux systems until patching is complete.
• Monitor vendor advisories for exact fixed versions and any change in exploit maturity, especially because kernel memory-corruption flaws can become more actionable after patch diffing.