[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <db8819b7-05d5-468d-8974-3dfae25bbb2b@rowland.harvard.edu>
Date: Sat, 1 Feb 2025 11:52:20 -0500
From: Alan Stern <stern@...land.harvard.edu>
To: Thinh Nguyen <Thinh.Nguyen@...opsys.com>
Cc: Roy Luo <royluo@...gle.com>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"andre.draszik@...aro.org" <andre.draszik@...aro.org>
Subject: Re: [PATCH v1] usb: dwc3: gadget: fix gadget workqueue use-after-free
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@...opsys.com> 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.
Alan Stern
Powered by blists - more mailing lists