The ACPI notify handler ucsi_acpi_notify() calls
ua->ucsi->ops->read_cci() and ucsi_notify_common(), both of which
dereference ua->ucsi with no NULL guard.  In ucsi_acpi_remove(),
ucsi_destroy() frees ua->ucsi (kfree) before
acpi_remove_notify_handler() is called, so a notify dispatch already
in flight on another CPU may access the freed object after
ucsi_destroy().

  CPU 0 (remove)                    | CPU 1 (ACPI notify wq)
    ucsi_destroy(ua->ucsi)          |   ucsi_acpi_notify(ua)
      kfree(ucsi) // FREE           |     ua->ucsi->ops->read_cci(...) // USE

Move acpi_remove_notify_handler() before ucsi_destroy() in the remove
path.  It is kept after ucsi_unregister(): ucsi_unregister() cancels
connector work whose handler issues GET_CONNECTOR_STATUS through
ucsi_send_command_common(), which waits for a completion that is
signalled from the notify path, so the handler must stay registered
until that work has been cancelled.

acpi_remove_notify_handler() drains in-flight notify dispatches before
returning: it calls acpi_os_wait_events_complete(), which flushes
kacpi_notify_wq. Because ACPI device-notify dispatch is deferred to that
same workqueue (acpi_os_execute(OSL_NOTIFY_HANDLER, ...)), the flush
guarantees any queued or running ucsi_acpi_notify() has returned before
the function returns, so ucsi_destroy() frees an object no handler can
reach. This mirrors commit 1f0bdc2884b6 ("usb: typec: ucsi: ccg: Fix
use-after-free of ucsi on remove"), which moved free_irq() before
ucsi_destroy() with the same ordering rationale.

The probe error paths already order acpi_remove_notify_handler() (or
omit it, when install failed) before ucsi_destroy(), and are unchanged.

This issue was found by an in-house static analysis tool.

Fixes: f56de278e8ec ("usb: typec: ucsi: acpi: Move to the new API")
Cc: stable@vger.kernel.org
Assisted-by: Codex:gpt-5.6
Signed-off-by: Fan Wu <fanwu01@zju.edu.cn>
---
 drivers/usb/typec/ucsi/ucsi_acpi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/typec/ucsi/ucsi_acpi.c b/drivers/usb/typec/ucsi/ucsi_acpi.c
index 60b12961e..1d56eadc9 100644
--- a/drivers/usb/typec/ucsi/ucsi_acpi.c
+++ b/drivers/usb/typec/ucsi/ucsi_acpi.c
@@ -257,10 +257,10 @@ static void ucsi_acpi_remove(struct platform_device *pdev)
 	struct ucsi_acpi *ua = platform_get_drvdata(pdev);
 
 	ucsi_unregister(ua->ucsi);
-	ucsi_destroy(ua->ucsi);
 
 	acpi_remove_notify_handler(ACPI_HANDLE(&pdev->dev), ACPI_DEVICE_NOTIFY,
 				   ucsi_acpi_notify);
+	ucsi_destroy(ua->ucsi);
 }
 
 static int ucsi_acpi_resume(struct device *dev)
-- 
2.34.1

On Sat, Jul 18, 2026 at 02:11:42AM +0000, Fan Wu wrote:
> The ACPI notify handler ucsi_acpi_notify() calls
> ua->ucsi->ops->read_cci() and ucsi_notify_common(), both of which
> dereference ua->ucsi with no NULL guard.  In ucsi_acpi_remove(),
> ucsi_destroy() frees ua->ucsi (kfree) before
> acpi_remove_notify_handler() is called, so a notify dispatch already
> in flight on another CPU may access the freed object after
> ucsi_destroy().
> 
>   CPU 0 (remove)                    | CPU 1 (ACPI notify wq)
>     ucsi_destroy(ua->ucsi)          |   ucsi_acpi_notify(ua)
>       kfree(ucsi) // FREE           |     ua->ucsi->ops->read_cci(...) // USE
> 
> Move acpi_remove_notify_handler() before ucsi_destroy() in the remove
> path.  It is kept after ucsi_unregister(): ucsi_unregister() cancels
> connector work whose handler issues GET_CONNECTOR_STATUS through
> ucsi_send_command_common(), which waits for a completion that is
> signalled from the notify path, so the handler must stay registered
> until that work has been cancelled.
> 
> acpi_remove_notify_handler() drains in-flight notify dispatches before
> returning: it calls acpi_os_wait_events_complete(), which flushes
> kacpi_notify_wq. Because ACPI device-notify dispatch is deferred to that
> same workqueue (acpi_os_execute(OSL_NOTIFY_HANDLER, ...)), the flush
> guarantees any queued or running ucsi_acpi_notify() has returned before
> the function returns, so ucsi_destroy() frees an object no handler can
> reach. This mirrors commit 1f0bdc2884b6 ("usb: typec: ucsi: ccg: Fix
> use-after-free of ucsi on remove"), which moved free_irq() before
> ucsi_destroy() with the same ordering rationale.
> 
> The probe error paths already order acpi_remove_notify_handler() (or
> omit it, when install failed) before ucsi_destroy(), and are unchanged.
> 
> This issue was found by an in-house static analysis tool.
> 
> Fixes: f56de278e8ec ("usb: typec: ucsi: acpi: Move to the new API")
> Cc: stable@vger.kernel.org
> Assisted-by: Codex:gpt-5.6
> Signed-off-by: Fan Wu <fanwu01@zju.edu.cn>
> ---
>  drivers/usb/typec/ucsi/ucsi_acpi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/typec/ucsi/ucsi_acpi.c b/drivers/usb/typec/ucsi/ucsi_acpi.c
> index 60b12961e..1d56eadc9 100644
> --- a/drivers/usb/typec/ucsi/ucsi_acpi.c
> +++ b/drivers/usb/typec/ucsi/ucsi_acpi.c
> @@ -257,10 +257,10 @@ static void ucsi_acpi_remove(struct platform_device *pdev)
>  	struct ucsi_acpi *ua = platform_get_drvdata(pdev);
>  
>  	ucsi_unregister(ua->ucsi);
> -	ucsi_destroy(ua->ucsi);
>  
>  	acpi_remove_notify_handler(ACPI_HANDLE(&pdev->dev), ACPI_DEVICE_NOTIFY,
>  				   ucsi_acpi_notify);
> +	ucsi_destroy(ua->ucsi);
>  }

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

> 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?

thanks,
Fan

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