CVE-2026-63905

What it actually does

This is a Linux kernel use-after-free race in the USB/IP virtual USB Device Controller (vudc) driver. A timer embedded in the vudc object can remain pending or executing while device removal/unbind frees the containing structure. When the kernel timer subsystem later walks or updates that freed timer memory, it can trigger memory corruption, kernel crash, or potentially enable privilege escalation depending on kernel configuration, heap layout, and attacker control. Exploitation requires access to the vulnerable usbip vudc interface and the ability to exercise the socket-fd write plus device unbind/rebind path; it is not a remotely reachable network flaw by default.

Why it matters to the business

Systems that load and expose the Linux USB/IP vudc driver may be vulnerable to local denial of service through kernel panic or instability. In higher-risk scenarios, a local attacker with sufficient access to manipulate the vudc sysfs controls could attempt kernel memory corruption for privilege escalation. The currently reported EPSS is very low, it is not listed in CISA KEV, and no public exploit maturity is reported, so broad active exploitation is not indicated; however, kernel memory-safety flaws should still be prioritized on systems using USB/IP, virtualization, embedded USB gadget workflows, CI fuzzing hosts, or development environments where untrusted users can access device-management interfaces.

How an attack unfolds

An attacker first needs a system where the usbip vudc driver is present, loadable, and accessible through sysfs or related device-management controls. They create or obtain a socket descriptor and write it to the usbip_sockfd control path, causing the vudc code to start or kick its transfer timer. While that timer is pending or racing on another CPU, the attacker triggers device unbind/removal of usbip-vudc.0. On vulnerable kernels, vudc_remove() frees the vudc object without synchronously stopping the embedded timer. The kernel timer code may then access the freed timer_list inside the freed object, producing a slab use-after-free. The most likely visible result is a KASAN report, kernel oops, panic, or system instability; with additional exploit engineering, the memory corruption primitive may be investigated for local privilege escalation.

How to fix it

Update to a Linux kernel build that includes the upstream fix for the usbip vudc removal path, specifically the change that calls v_stop_timer() from vudc_remove() and deletes the timer synchronously before freeing the vudc object. If vendor fixed package versions are not yet available, track the relevant distribution kernel advisories and apply the first kernel update that references this issue or the usbip vudc use-after-free fix. As interim mitigation, disable or unload the usbip-vudc driver where it is not required, avoid exposing USB/IP vudc controls to untrusted local users, restrict write access to related sysfs driver bind/unbind and usbip_sockfd attributes, and limit CAP_SYS_ADMIN or equivalent device-management privileges in containers and shared systems. Reboot after kernel updates or module replacement to ensure the vulnerable code is no longer running.

How to confirm the fix worked

Confirm the running kernel is a vendor-supported build containing the usbip vudc timer-stop fix; checking only the installed package is insufficient if the host has not rebooted. Verify whether the usbip-vudc module is loaded with tools such as lsmod or by checking /sys/module/usbip_vudc and related sysfs driver paths. If USB/IP vudc is not needed, validate that the module is absent, blacklisted, or not loadable by unprivileged workflows. On test systems, reproduce the bind/unbind and usbip_sockfd stress path only in an isolated lab: patched kernels should complete repeated cycles without KASAN use-after-free reports, kernel oopses, or timer-core crashes. Review distribution changelogs or kernel commit history for references to vudc_remove(), v_stop_timer(), usbip vudc, or the assigned vulnerability identifier.

Typical attack path

1. Identify a Linux host with CONFIG_USBIP_VUDC enabled or the usbip-vudc module available and loaded.
2. Confirm the attacker has local permissions to interact with USB/IP vudc sysfs controls or can influence a privileged process that does.
3. Create a socket pair or otherwise obtain a socket file descriptor suitable for the usbip_sockfd interface.
4. Write the socket file descriptor to the vudc usbip_sockfd attribute to start or kick the vudc timer.
5. Close or disrupt the socket while repeatedly unbinding and rebinding the usbip-vudc.0 platform device.
6. Win the race where vudc_remove() frees the vudc object while its embedded timer remains pending or executing.
7. Cause kernel use-after-free behavior, typically resulting in a crash/oops and potentially providing a path for local kernel memory corruption exploitation.

How to detect it

To assess prior exploitation, review kernel logs and persistent system journals for crashes or memory-safety reports involving usbip-vudc, vudc_remove, v_timer, timer_list, __run_timer_base, or unbind_store. Useful sources include dmesg output, /var/log/kern.log, /var/log/messages, systemd journal kernel facility logs, crash dump metadata, kdump/vmcore analysis, auditd records for sysfs writes, and EDR telemetry for processes repeatedly writing to USB/IP sysfs controls. Look for sequences where usbip_sockfd writes are followed by rapid unbind/rebind of usbip-vudc.0, socket closures, kernel oopses, KASAN slab-use-after-free reports, or unexpected reboots. If audit rules are available, search for writes to USB/IP vudc sysfs attributes and platform driver unbind/bind paths by nonstandard processes or users. Absence of KASAN output does not prove absence of exploitation because production kernels often do not enable KASAN; in those cases, unexplained kernel panics near USB/IP or timer code are the strongest retrospective artifacts.

• BUG: KASAN: slab-use-after-free in __run_timer_base
• slab-use-after-free in __run_timer_base.part.0
• vudc_remove
• vudc_probe
• v_timer
• v_start_timer
• v_kick_timer
• v_stop_timer
• usbip_sockfd
• usbip-vudc.0
• unbind_store
• device_release_driver_internal
• /sys/bus/platform/drivers/usbip-vudc/unbind
• /sys/bus/platform/drivers/usbip-vudc/bind
• /sys/module/usbip_vudc
• CONFIG_USBIP_VUDC
• timer_list
• Write of size 8 at addr
• Freed by task
• Allocated by task

What your security team should do

• Inventory Linux systems that have USB/IP enabled, the usbip-vudc module loaded, or kernel configurations containing CONFIG_USBIP_VUDC.
• Prioritize patching systems where untrusted local users, containers, CI jobs, test harnesses, or automation can access USB/IP or device bind/unbind sysfs controls.
• Apply vendor kernel updates that include the vudc_remove timer synchronization fix, then reboot into the fixed kernel.
• Disable or blacklist usbip-vudc on systems that do not explicitly require USB/IP virtual device controller functionality.
• Restrict administrative capabilities that allow writing to sysfs driver bind/unbind attributes or USB/IP control attributes, especially in multi-user and containerized environments.
• Monitor kernel logs for KASAN, slab use-after-free, timer subsystem crashes, and repeated usbip-vudc unbind/rebind activity.
• Because the issue is not currently in CISA KEV and has low EPSS, treat it as targeted local-risk hardening unless USB/IP is broadly deployed or exposed to untrusted local workloads.