Re: [PATCH v1] usb: dwc3: gadget: fix gadget workqueue use-after-free

From: Roy Luo
Date: Mon Feb 03 2025 - 19:05:02 EST


On Mon, Feb 3, 2025 at 3:54 PM Thinh Nguyen <Thinh.Nguyen@xxxxxxxxxxxx> wrote:
>
> On Sat, Feb 01, 2025, Alan Stern wrote:
> > On Fri, Jan 31, 2025 at 11:44:17PM +0000, Thinh Nguyen wrote:
> > > Cc Alan
> > >
> > > On Fri, Jan 31, 2025, Roy Luo wrote:
> > > > On Mon, Jan 27, 2025 at 5:44 PM Thinh Nguyen <Thinh.Nguyen@xxxxxxxxxxxx> wrote:
> > > > >
> > > > > On Wed, Jan 22, 2025, Roy Luo wrote:
> > > > > > `dwc3_gadget_soft_disconnect` function, called as part of
> > > > >
> > > > > The dwc3_gadget_soft_disconnect() isn't directly part of
> > > > > device_del(&gadget->dev). It should be part of disconnect.
> > > > >
> > > > > Can you provide the full sequence of events so I can have more context?
> > > > > The handling of the flushing of gadget->work should not be part of the
> > > > > dwc3.
> > > >
> > > >
> > > > Yes, it's a part of disconnect, and disconnect is a part of gadget unbind.
> > > > Let me try my best to explain. Here's the call stack for usb_del_gadget:
> > > > -> usb_del_gadget
> > > > -> flush_work(&gadget->work)
> > > > -> device_del
> > > > -> bus_remove_device
> > > > -> device_release_driver
> > > > -> gadget_unbind_driver
> > > > -> usb_gadget_disconnect_locked
> > > > -> dwc3_gadget_pullup
> > > > -> dwc3_gadget_soft_disconnect
> > > > -> usb_gadget_set_state
> > > > -> schedule_work(&gadget->work)
> > > >
> > > > Then when usb_put_gadget is called, gadget could be freed before
> > > > gadget->work is executed.
> > > > -> usb_put_gadget
> > > > -> put_device
> > > > -> kobject_put
> > > > -> device_release
> > > > -> dwc_gadget_release
> > > > -> kfree(gadget)
> > > >
> > >
> > > Thanks for the details!
> > >
> > > The UDC core is initiating and handling the gadget->work, so the
> > > flushing of the gadget->work should also be handled there.
> > >
> > > Since the usb_gadget_disconnect_locked() may trigger a state change work
> > > on unbind, the flushing of the gadget->work should to be moved to
> > > gadget_unbind_driver() instead:
> > >
> > > diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c
> > > index f8c1ef465e45..9e4abd6e40f8 100644
> > > --- a/drivers/usb/gadget/udc/core.c
> > > +++ b/drivers/usb/gadget/udc/core.c
> > > @@ -1568,7 +1568,6 @@ void usb_del_gadget(struct usb_gadget *gadget)
> > >
> > > kobject_uevent(&udc->dev.kobj, KOBJ_REMOVE);
> > > sysfs_remove_link(&udc->dev.kobj, "gadget");
> > > - flush_work(&gadget->work);
> > > device_del(&gadget->dev);
> > > ida_free(&gadget_id_numbers, gadget->id_number);
> > > cancel_work_sync(&udc->vbus_work);
> > > @@ -1694,6 +1693,8 @@ static void gadget_unbind_driver(struct device *dev)
> > > synchronize_irq(gadget->irq);
> > > mutex_unlock(&udc->connect_lock);
> > >
> > > + flush_work(&gadget->work);
> > > +
> > > udc->driver->unbind(gadget);
> > >
> > > mutex_lock(&udc->connect_lock);
> >
> > What about instead moving the flush_work() call down just one line,
> > after the device_del(&gadget->dev) call rather than before it?
> >
> > The work queue doesn't need to be flushed every time a driver unbinds
> > from the gadget, only when the gadget is about to be deallocated.
> >
>
> That sounds good to me.
>
> Thanks,
> Thinh

Thank both of you for the review!
I've sent out https://lore.kernel.org/linux-usb/20250204000102.3989779-1-royluo@xxxxxxxxxx
per Alan's suggestion.

Regards,
Roy