CVE-2026-64331

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usbip: vudc: fix NULL deref in vep_dequeue()<br /> <br /> vep_alloc_request() wasn&amp;#39;t initializing vrequest-&gt;udc, so cancellations<br /> on the FunctionFS AIO path were arriving in vep_dequeue without a valid<br /> UDC reference.<br /> <br /> Since vrequest-&gt;udc is never actually properly used anywhere, we opt to<br /> remove it, and update vep_dequeue to obtain a reference to the udc with<br /> ep_to_vudc(), consistent with the other vep_ ops.<br /> <br /> AFAICT this bug has existed for ~10 years. Seems that nobody has really<br /> stressed the FunctionFS AIO path on usbip&amp;#39;s vudc.<br /> <br /> I tested this fix in a QEMU aarch64 guest driving FunctionFS endpoints<br /> via AIO. Before the fix, running `usbip attach` from the host would<br /> cause the guest to oops with the following backtrace:<br /> <br /> Call trace:<br /> vep_dequeue+0x1c/0xe4 (P)<br /> usb_ep_dequeue+0x14/0x20<br /> ffs_aio_cancel+0x24/0x34<br /> __arm64_sys_io_cancel+0xb0/0x124<br /> do_el0_svc+0x68/0x100<br /> el0_svc+0x18/0x5c<br /> el0t_64_sync_handler+0x98/0xdc<br /> el0t_64_sync+0x154/0x158