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

[Heikki Krogerus <heikki.krogerus@linux.intel.com>]

Hi Fan,

On Tue, Jul 21, 2026 at 10:47:59PM +0800, Fan Wu wrote:
> 
> 
> > On Jul 21, 2026, at 16:27, Heikki Krogerus <heikki.krogerus@linux.intel.com> 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?

Let's keep this in ucsi_acpi.c for now.

Thanks,

-- 
heikki