Re: [PATCH] usb: chipidea: fix usage_count leak when autosuspend_delay is negative

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] Background tasks and timers are not properly canceled during driver removal, leading to Use-After-Free.
- [High] The hardware is put into low power mode during removal without disabling the devm-managed shared IRQ, leading to a kernel crash if the IRQ fires.
--

--- Patch [1]: [PATCH] usb: chipidea: fix usage_count leak when autosuspend_delay is negative ---
commit fdadfb5f628818e9f20b2b5de671e334ccae62bf
Author: Xu Yang <xu.yang_2@nxp.com>

usb: chipidea: fix usage_count leak when autosuspend_delay is negative

The probe function calls pm_runtime_use_autosuspend(), but the remove
function misses the corresponding pm_runtime_dont_use_autosuspend() call.
This fixes a usage count leak when autosuspend_delay is set to a negative
value.

> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> index 07563be0013f4..b53672f3ea634 100644
> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -1250,6 +1250,7 @@ static void ci_hdrc_remove(struct platform_device *pdev)
>  		usb_role_switch_unregister(ci->role_switch);
>  
>  	if (ci->supports_runtime_pm) {
> +		pm_runtime_dont_use_autosuspend(&pdev->dev);
>  		pm_runtime_get_sync(&pdev->dev);
>  		pm_runtime_disable(&pdev->dev);
>  		pm_runtime_put_noidle(&pdev->dev);

[Severity: High]
This is a pre-existing issue, but does this driver leave background tasks
running after removal?

Looking at the remainder of ci_hdrc_remove(), it finishes with:

	dbg_remove_files(ci);
	ci_role_destroy(ci);
	ci_hdrc_enter_lpm(ci, true);
	ci_usb_phy_exit(ci);
	ci_ulpi_exit(ci);
}

The ci structure is devres-managed and will be freed after ci_hdrc_remove()
completes, but ci->otg_fsm_hrtimer and ci->power_lost_work are not
explicitly canceled during this teardown.

If the hrtimer fires or the work executes after this point, could it cause a
use-after-free? Furthermore, since the timer queues work to ci->wq, which is
destroyed in ci_hdrc_otg_destroy(), would a firing timer attempt to use a
destroyed workqueue?

[Severity: High]
This is also a pre-existing issue, but does entering low power mode during
removal leave a race window with the shared IRQ?

In ci_hdrc_remove(), the hardware is powered down by calling
ci_hdrc_enter_lpm(ci, true).

Because the interrupt is requested as devm-managed and IRQF_SHARED, it
remains active until devres cleanup runs after the remove function returns.
If another device on the same shared IRQ line triggers an interrupt during
this window, ci_irq_handler() will execute.

Since ci->in_lpm was not set to true before powering down, will the handler
bypass the low-power early exit check and crash attempting to read
powered-down registers?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260716104126.2763454-1-xu.yang_2@oss.nxp.com?part=1