Re: [PATCH] usbip: vudc: fix NULL deref in vep_dequeue()

[Igor Kotrasinski/Security (PLT) /SRPOL/Engineer/Samsung Electronics]

Hi,

> From: Sam Day <me@xxxxxxxxxxx>
> 
> vep_alloc_request() wasn't initializing vrequest->udc, so cancellations
> on the FunctionFS AIO path were arriving in vep_dequeue without a valid
> UDC reference.
> 
> 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:
>   vep_dequeue+0x1c/0xe4 (P)
>   usb_ep_dequeue+0x14/0x20
>   ffs_aio_cancel+0x24/0x34
>   __arm64_sys_io_cancel+0xb0/0x124
>   do_el0_svc+0x68/0x100
>   el0_svc+0x18/0x5c
>   el0t_64_sync_handler+0x98/0xdc
>   el0t_64_sync+0x154/0x158
> 
> Assisted-by: opencode:openai/gpt-5.5
> Fixes: b6a0ca111867 ("usbip: vudc: Add UDC specific ops")
> Signed-off-by: Sam Day <me@xxxxxxxxxxx>
> ---
>   drivers/usb/usbip/vudc_dev.c | 3 +++
>   1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/usb/usbip/vudc_dev.c b/drivers/usb/usbip/vudc_dev.c
> index c5f079c5a1ea..2f1f141909b2 100644
> --- a/drivers/usb/usbip/vudc_dev.c
> +++ b/drivers/usb/usbip/vudc_dev.c
> @@ -279,15 +279,18 @@ static int vep_disable(struct usb_ep *_ep)
>   static struct usb_request *vep_alloc_request(struct usb_ep *_ep,
>   		gfp_t mem_flags)
>   {
> +	struct vep *ep;
>   	struct vrequest *req;
>   
>   	if (!_ep)
>   		return NULL;
> +	ep = to_vep(_ep);
>   
>   	req = kzalloc_obj(*req, mem_flags);
>   	if (!req)
>   		return NULL;
>   
> +	req->udc = ep_to_vudc(ep);

We can get rid of udc in struct vrequest and call ep_to_vudc() in 
vep_dequeue(). All the other places do it, I think I missed that one 
during a refactor before submitting the driver.

>   	INIT_LIST_HEAD(&req->req_entry);
>   
>   	return &req->req;
> 
> ---
> base-commit: 5cd1731cc883a9914d91e3b93d4597317b5b5339
> change-id: 20260619-usbip-vudc-deque-fix-d316de3d3f16
> 
> Best regards,

Side note, there are some checks for udc->driver being NULL that I feel 
are either redundant or should be behind a spinlock, just like setting 
udc->driver is. I'm not sure which, will have to take a look.

BRs,

Igor Kotrasiński