CVE-2026-64331

What it actually does

CVE-2026-64331 is a Linux kernel NULL pointer dereference in the usbip virtual USB device controller implementation, specifically in the vudc endpoint dequeue path. The bug occurs because a request allocated by vep_alloc_request() did not initialize the request’s UDC reference, and FunctionFS asynchronous I/O cancellation can reach vep_dequeue() without a valid controller pointer. When the affected path is triggered, the kernel can dereference NULL and produce an oops/panic depending on kernel configuration, causing denial of service for the affected system or virtual guest using usbip vudc and FunctionFS AIO.

Why it matters to the business

Successful exploitation can crash or destabilize Linux systems that expose or use usbip virtual USB device functionality with FunctionFS asynchronous I/O, potentially interrupting workloads, embedded device functions, test infrastructure, virtualization environments, or USB-over-IP services. The currently reported EPSS is low and there is no known CISA KEV listing or ransomware association, but kernel denial-of-service issues still matter where local users, guest workloads, or USB-over-IP interactions are exposed to less-trusted parties.

How an attack unfolds

An attacker needs access to an environment where the vulnerable Linux kernel usbip vudc and FunctionFS AIO code paths are reachable. In a representative scenario, a guest or device-side environment configures FunctionFS endpoints and performs asynchronous I/O. A cancellation of an outstanding AIO request invokes ffs_aio_cancel(), which calls usb_ep_dequeue() and reaches vep_dequeue(). Because the request lacks a valid UDC reference in vulnerable kernels, vep_dequeue() dereferences a NULL pointer. The result is a kernel oops and possible kernel panic, terminating service availability. Public evidence currently describes a crash trigger demonstrated using a QEMU aarch64 guest and usbip attach from the host rather than active in-the-wild exploitation.

How to fix it

Apply vendor-provided Linux kernel updates that include the usbip vudc fix for vep_dequeue(). The upstream fix removes reliance on the uninitialized request UDC field and obtains the controller reference via ep_to_vudc(), consistent with other vep operations. Because no specific affected product or fixed package version was provided, security teams should track their distribution kernel advisories and update to the first kernel build containing the fix for this CVE. Where immediate patching is not possible, reduce exposure by disabling usbip/vudc functionality if unused, unloading related modules where operationally safe, restricting access to USB-over-IP control paths, and limiting untrusted users or workloads from configuring FunctionFS endpoints or issuing AIO cancellation flows.

How to confirm the fix worked

Confirm remediation by checking that the running kernel package includes the distribution fix for this vulnerability, not merely that an updated package is installed but unused. Validate with uname -a and package-manager kernel version checks after reboot. Review loaded modules and configuration to determine whether usbip/vudc and FunctionFS are enabled or in use. In controlled non-production testing, the previously crashing workflow involving FunctionFS AIO cancellation and usbip attach should no longer produce an oops in vep_dequeue(). Exposure is lower on systems where usbip virtual device controller support is not built, not loaded, and not reachable by untrusted users or workloads.

Typical attack path

1. Identify a Linux system, guest, or embedded environment using usbip virtual device controller functionality.
2. Ensure or wait for FunctionFS endpoints to be active with asynchronous I/O requests pending.
3. Trigger or induce cancellation of FunctionFS AIO operations, such as through attach/detach or endpoint activity that reaches usb_ep_dequeue().
4. Cause execution of the vulnerable vep_dequeue() path with an invalid UDC reference.
5. Crash the kernel or produce a kernel oops, resulting in denial of service.

How to detect it

Look for evidence of prior kernel crashes or oops events involving the usbip vudc dequeue path. Relevant sources include dmesg output, journald kernel logs, /var/log/kern.log, /var/log/messages, crash dump repositories, kdump/vmcore records, hypervisor console logs for guests, and monitoring alerts for unexpected reboots. Search for stack traces containing vep_dequeue, usb_ep_dequeue, ffs_aio_cancel, __arm64_sys_io_cancel, FunctionFS, vudc, or usbip around the time of service interruption. Also review command and audit logs, where available, for usbip attach/detach activity or processes interacting with FunctionFS endpoints before the crash. There are no known public threat actors, ransomware campaigns, or stable malware artifacts associated with this issue at this time; detection is primarily crash-forensics based rather than network IOC based.

• vep_dequeue
• usb_ep_dequeue
• ffs_aio_cancel
• __arm64_sys_io_cancel
• usbip attach
• usbip detach
• vudc
• FunctionFS
• kernel oops
• Unable to handle kernel NULL pointer dereference

What your security team should do

• Inventory Linux hosts, guests, embedded devices, and lab systems using usbip, vudc, USB gadget, or FunctionFS functionality.
• Prioritize kernel updates for systems where usbip or USB gadget functionality is exposed to untrusted users, tenants, guests, or remote USB-over-IP clients.
• If usbip/vudc is not required, disable or unload the relevant functionality and prevent automatic module loading where feasible.
• Monitor kernel logs for oops or panic traces involving vep_dequeue, usb_ep_dequeue, ffs_aio_cancel, or FunctionFS AIO cancellation.
• Coordinate with platform, virtualization, and embedded engineering teams because this issue may affect specialized USB-over-IP or gadget workflows rather than typical server applications.
• Do not treat the low EPSS score as a reason to ignore internet- or tenant-exposed kernel attack surfaces; treat it as lower likelihood but potentially high operational impact where the feature is used.