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

[Sam Day]

Hello Igor,

On Friday, 19 June 2026 at 10:34 PM, Igor Kotrasinski/Security (PLT) /SRPOL/Engineer/Samsung Electronics <i.kotrasinsk@xxxxxxxxxxx> wrote:

> 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.

Thanks, I've done exactly that in v2.

> 
> >   	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.

Hmmm, I took a brief look at this but it seems to be quite the can of worms.
Since it appears unrelated to the vrequest->udc NULL deref and falls outside
my domain of experience/expertise/confidence-levels, I'll leave this follow-up
to the pros :)

Cheers,
-Sam

> 
> BRs,
> 
> Igor Kotrasiński
>