Re: [PATCH] usb: gadget: tegra-xudc: Disable port reset work on removal

[Thierry Reding]

On Thu, Sep 17, 2026 at 07:20:58PM +0000, Myeonghun Pak wrote:
> The port status interrupt can schedule port_reset_war_work to handle the
> Tegra210 port reset workaround. The remove path does not cancel this
> work, so it can run after the PHYs and controller resources have been
> released and access freed memory.
> 
> Disable and drain port_reset_war_work before tearing down the controller.
> Use disable_delayed_work_sync() so that the interrupt handler cannot
> queue the work again while the managed IRQ is still registered.
> 
> This issue was identified during our ongoing static-analysis research
> while reviewing kernel code.
> 
> Fixes: 49db427232fe ("usb: gadget: Add UDC driver for tegra XUSB
> device mode controller")

Please don't wrap lines like this.

> Cc: stable@xxxxxxxxxxxxxxx # 6.10+
> Assisted-by: LLM
> Co-developed-by: Ijae Kim <ae878000@xxxxxxxxx>
> Signed-off-by: Ijae Kim <ae878000@xxxxxxxxx>
> Signed-off-by: Myeonghun Pak <mhun512@xxxxxxxxx>
> ---
>  drivers/usb/gadget/udc/tegra-xudc.c |    1 +
>  1 file changed, 1 insertion(+)
> 
> --- a/drivers/usb/gadget/udc/tegra-xudc.c
> +++ b/drivers/usb/gadget/udc/tegra-xudc.c
> @@ -3926,6 +3926,7 @@
> 
>  	pm_runtime_get_sync(xudc->dev);
> 
> +	disable_delayed_work_sync(&xudc->port_reset_war_work);
>  	cancel_delayed_work_sync(&xudc->plc_reset_work);
>  	cancel_work_sync(&xudc->usb_role_sw_work);

This is a preexisting problem, but given that we only delete the gadget
below this cleanup, shouldn't the other two cancel_*() calls be
disable_*() as well? Otherwise there's potentially a race condition
between this and the interrupt handler (which is only unregistered after
.remove() completes).

Either that or the existing cancel_*() calls are enough in which case
your patch probably should be using that variant as well.

Thierry

Attachment: signature.asc
Description: PGP signature