Re: [PATCH] usb: gadget: lpc32xx_udc: cancel pullup work on remove

[Aldo Ariel Panzardo <qwe.aldo@gmail.com>]

On Mon, Sep 28, 2026 at 09:41:58PM +0800, Hongyan Xu wrote:
> Several device interrupts can queue pullup_job, whose callback accesses
> the UDC and its I2C transceiver. The IRQs are device-managed, so they
> remain registered throughout the driver remove callback, and no path
> drains work queued before the resources are released.

The use-after-free is real and the shape of the fix is right. The suspend
and resume interrupt paths both schedule_work(&udc->pullup_job), and the
device-managed IRQs stay live until after remove() returns, so disabling
the four IRQs before teardown and draining the work before
put_device(&udc->isp1301_i2c_client->dev) does close the window.

One side effect is worth reconsidering, though. remove() calls
pullup(udc, 0) right before the cancel. For a gadget that was enumerated
that reaches isp1301_pullup_enable(udc, 0, 0), which only defers the
actual transceiver write via schedule_work(); cancel_work_sync() then
discards that work before it runs, since the IRQs are already disabled and
nothing re-queues it. udc_disable() touches only the UDC core, not the
ISP1301, so the D+ pull-up is left asserted -- the explicit pullup(udc, 0)
ends up doing nothing on the common path and the device does not
electrically disconnect on removal.

Draining with flush_work() instead (or clearing the pull-up synchronously
before the cancel) would both close the use-after-free and keep the
disconnect: a job still queued runs with udc->pullup already 0, so it
performs the clear while the i2c client is still valid.

Thanks,
Aldo