Re: [PATCH v1] scsi: ufs: core: Hold a clock reference across the probe

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [Critical] Missing scsi_remove_host() on the ufshcd_init() error path leaves dangling sysfs references leading to use-after-free.
--

commit a971113b5d6d58a777d3955df4f8947756e7eb86
Author: Naomi Chu <naomi.chu@mediatek.com>

scsi: ufs: core: Hold a clock reference across the probe

This patch modifies the UFS core to take a clock reference as soon as clock
gating is initialized and holds it until the probe finishes or fails. This
ensures register accesses during the probe do not depend on the host state
and prevents them from occurring without a held clock reference.

> diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
> index ee21388e74f5f..7d63287b5ca94 100644
> --- a/drivers/ufs/core/ufshcd.c
> +++ b/drivers/ufs/core/ufshcd.c

[ ... ]

> @@ -11322,7 +11326,7 @@ int ufshcd_init(struct ufs_hba *hba, void __iomem *mmio_base, unsigned int irq)
>  
>  	err = ufshcd_add_scsi_host(hba);
>  	if (err)
> -		goto out_disable;
> +		goto out_release;
>  
>  	/* Hold auto suspend until async scan completes */
>  	pm_runtime_get_sync(dev);

[ ... ]

> @@ -11386,6 +11390,8 @@ int ufshcd_init(struct ufs_hba *hba, void __iomem *mmio_base, unsigned int irq)
>  	ufshcd_pm_qos_init(hba);
>  	return 0;
>  
> +out_release:
> +	ufshcd_release(hba);
>  out_disable:
>  	hba->is_irq_enabled = false;
>  	ufshcd_hba_exit(hba);

[Severity: Critical]
This is a pre-existing issue, but does this error path leave the SCSI host
registered in sysfs if a failure occurs later in the initialization?

If ufshcd_init() fails after successfully calling ufshcd_add_scsi_host()
(for example, if ufshcd_link_startup() or ufshcd_verify_dev_init() fails
and jumps to out_release), the function returns an error without calling
scsi_remove_host().

Since the driver probe fails, devres will free managed resources such as
the MMIO region mappings and IRQs. However, the SCSI host would remain
registered in sysfs.

Could a subsequent interaction with these orphaned sysfs nodes invoke SCSI
callbacks that attempt to access the unmapped MMIO base and freed memory,
potentially leading to a use-after-free and system crash?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260909091045.1134956-1-naomi.chu@mediatek.com?part=1