Re: [PATCH] usb: typec: ucsi: acpi: Fix use-after-free of ucsi on remove

[Fan Wu]

> On Jul 21, 2026, at 16:27, Heikki Krogerus <heikki.krogerus@xxxxxxxxxxxxxxx> wrote:
> 
> 
> I don't think this is enough. You now create a window where the ucsi
> is unregistered, but you can still call ucsi_notify_common(),
> ucsi_connector_change(), etc. So you'll end up with even more problems.
> 
> If I understood correctly the long explanation (I'm guessing generated
> by gpt-5.6), the problem is that ucsi_unregister() disables the
> notification, but it does not flush them. My proposal is that you fix
> that by setting the ua->ucsi to NULL after calling ucsi_unregister()
> and then always check it in ucsi_acpi_notify(). You probable also need
> a lock for that.
> 
> thanks,
> 
> -- 
> heikki

Thank you, you are right. The proposed reordering does not protect the
connector state freed by ucsi_unregister(), while the notify handler can
still enter ucsi_notify_common() and ucsi_connector_change().

I also see that simply serializing the handler with ucsi_unregister()
could prevent pending command completions needed by work being cancelled
there. Thus, a driver-local reorder or NULL check alone is not sufficient.

I will drop this patch and investigate the appropriate synchronization
scheme. Do you have a preferred direction: should this be handled by a
core-UCSI quiesce interface, or by a transport-side locking protocol?

thanks,
Fan