CVE-2026-64348

What it actually does

This flaw is a Linux kernel memory-management bug in the USB host controller code for EHCI and FOTG210 isochronous transfers. When an isochronous USB Request Block submission fails before the URB is linked to the endpoint queue, the kernel can leave an allocated EHCI isochronous schedule referenced through urb->hcpriv instead of freeing it. Repeated failed submissions can leak kernel memory. The most likely technical consequence is local denial of service through memory exhaustion or degraded system stability on systems using affected USB host controller paths with isochronous USB devices, such as audio, video, or other time-sensitive USB peripherals.

Why it matters to the business

Successful exploitation could cause affected Linux systems to become unstable, slow, or unavailable, especially systems that rely on USB peripherals or embedded/industrial hardware with EHCI/FOTG210 controllers. Because this is a kernel-level flaw, outages may require service restart or full host reboot to recover. Current public exploit maturity is listed as none, EPSS is low, and it is not in CISA KEV or known ransomware use, so urgency is lower than for actively exploited remote vulnerabilities; however, organizations with Linux systems that expose USB access to untrusted users, devices, kiosks, lab environments, or edge/embedded deployments should prioritize kernel updates during normal patch cycles.

How an attack unfolds

An attacker needs a way to cause repeated failing isochronous USB submissions through the affected Linux USB host controller path. In a realistic scenario, this may require local access, control over a connected USB device, or the ability to run code that interacts with an isochronous USB peripheral. The attacker triggers conditions where the controller is unavailable or where usb_hcd_link_urb_to_ep() fails before the URB is linked. In the vulnerable path, the staged EHCI isochronous schedule is not freed. By repeatedly exercising this failure path, the attacker can consume kernel memory over time. If enough memory is leaked, the system may experience memory pressure, service failures, hangs, or a crash, resulting in denial of service. There is no indication from the provided data that this vulnerability enables code execution or privilege escalation.

How to fix it

Apply a Linux kernel update that includes the fix for freeing the staged isochronous schedule on failed submit paths and clearing urb->hcpriv after free. Because no exact affected product list or fixed package versions were provided, use the fixed kernel packages supplied by the relevant Linux distribution, appliance vendor, or kernel maintainer once available. Prioritize systems with enabled USB host controller support, EHCI/FOTG210 hardware, externally accessible USB ports, kiosk or shared-access use cases, and workloads using isochronous USB devices. If immediate patching is not possible, reduce exposure by restricting physical USB access, disabling unused USB ports/controllers where operationally feasible, blocking untrusted USB devices, disabling unnecessary USB kernel modules or host controller support, and limiting local user access capable of exercising USB device interfaces.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel version or vendor kernel package includes the upstream fix for the EHCI/FOTG210 isochronous submit failure path. Validate that systems have rebooted into the patched kernel, not merely installed the package. Review distribution advisories and kernel changelogs for references to freeing iso schedules on failed submit, EHCI isochronous schedule cleanup, or the relevant CVE. For exposure validation, inventory Linux systems with EHCI/FOTG210 USB host controllers and USB isochronous device usage. Where safe, confirm that USB host controller modules and device access policies match the intended hardened configuration.

Typical attack path

1. Obtain local access to the Linux system, control a connected USB device, or run software that can submit USB isochronous transfers.
2. Interact with an EHCI or FOTG210 USB host controller using an isochronous USB workload, such as audio/video-style USB transfer behavior.
3. Trigger repeated failed URB submission paths before the URB is linked to the endpoint queue.
4. Cause the kernel to leak staged EHCI isochronous schedule allocations through the vulnerable error path.
5. Repeat the operation until kernel memory pressure degrades system performance, disrupts services, or causes a hang/reboot.

How to detect it

There are no unique network indicators for this vulnerability because exploitation is local or device-adjacent and occurs inside the kernel USB stack. To assess possible prior exploitation, review kernel logs, system journals, crash dumps, and monitoring telemetry for repeated USB host controller errors followed by growing memory pressure or denial-of-service symptoms. Useful sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, system crash dumps, OOM-killer logs, endpoint telemetry for unusual local processes repeatedly interacting with USB devices, and hardware inventory showing EHCI/FOTG210 controllers. Look for clusters of USB isochronous device activity, repeated URB submission failures, controller-not-accessible errors, USB resets/disconnects, and memory exhaustion events without an obvious workload explanation. Because the root issue is a memory leak, absence of a distinctive log line does not rule out exploitation; correlate USB errors with steadily declining available memory, slab growth, OOM events, hangs, or reboots.

• usb_hcd_link_urb_to_ep
• urb submit failed
• URB submit failed
• isochronous
• EHCI
• FOTG210
• ehci_hcd
• fotg210_hcd
• usb_submit_urb
• usb usb
• reset high-speed USB device
• USB disconnect
• host controller not responding
• HC died
• ehci-pci
• Out of memory
• oom-killer
• invoked oom-killer
• Memory allocation failure

What your security team should do

• Inventory Linux assets with USB host controller support, especially EHCI/FOTG210 controllers and systems using USB audio, video, capture, telephony, or other isochronous peripherals.
• Track vendor kernel advisories and schedule deployment of fixed kernel packages through the normal patch process; accelerate for shared, kiosk, lab, edge, embedded, or physically accessible systems.
• After patching, verify that each system has rebooted into the fixed kernel version.
• Restrict physical access to USB ports and block untrusted USB devices on systems where immediate patching is delayed.
• Disable unused USB controllers, ports, or kernel modules where this does not affect business operations.
• Monitor for unexplained kernel memory pressure, USB host controller errors, repeated USB device resets, and host instability on unpatched systems.
• Treat exploitation likelihood as currently low based on low EPSS, no known public exploit maturity, and no KEV listing, but reassess if exploit code, vendor advisories, or threat activity emerges.