CVE-2026-64331: usbip: vudc: fix NULL deref in vep_dequeue()
In the Linux kernel, the following vulnerability has been resolved:
usbip: vudc: fix NULL deref in vepdequeue()
vepallocrequest() wasn't initializing vrequest->udc, so cancellations on the FunctionFS AIO path were arriving in vepdequeue without a valid UDC reference.
Since vrequest->udc is never actually properly used anywhere, we opt to remove it, and update vepdequeue to obtain a reference to the udc with eptovudc(), consistent with the other vep ops.
AFAICT this bug has existed for ~10 years. Seems that nobody has really stressed the FunctionFS AIO path on usbip's vudc.
I tested this fix in a QEMU aarch64 guest driving FunctionFS endpoints via AIO. Before the fix, running usbip attach from the host would cause the guest to oops with the following backtrace:
Call trace: vepdequeue+0x1c/0xe4 (P) usbepdequeue+0x14/0x20 ffsaiocancel+0x24/0x34 arm64sysiocancel+0xb0/0x124 doel0svc+0x68/0x100 el0svc+0x18/0x5c el0t64synchandler+0x98/0xdc el0t64sync+0x154/0x158
Affected Software
Remediation
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
The affected path is USB/IP's virtual USB device controller (vudc) when FunctionFS endpoints are driven through asynchronous I/O. The reported failure occurred in a QEMU aarch64 guest after a host ran usbip attach.
What conditions are required to trigger the crash?
A cancellation must reach the FunctionFS AIO path and invoke vep_dequeue() without a valid UDC reference. The supplied test used FunctionFS endpoints via AIO, followed by usbip attach from the host.
How can I identify a likely occurrence?
An affected system may kernel oops during cancellation activity, with a call trace containing vep_dequeue, usb_ep_dequeue, ffs_aio_cancel, and __arm64_sys_io_cancel. The documented impact is a NULL-pointer dereference resulting in availability loss.
What should be done if the affected functionality is in use?
Apply an available kernel patch. If patching cannot happen immediately, the data supports avoiding the exposed combination of USB/IP vudc and FunctionFS AIO cancellation activity; no other workaround is provided.