Re: [GIT PULL] SCSI fixes for 7.3-rc4+

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] scsi: ufs: Use-After-Free on pseudo_sdev in ufshcd_err_handling_prepare()
- [Low] scsi: megaraid: mixing goto-based error handling and scoped_guard in megasas_resume
--

commit 779f0b1927d5f926d874e86dcf935da1578ca2f4
Author: James Bottomley <James.Bottomley@HansenPartnership.com>
Date:   Fri Sep 25 21:22:51 2026 +0000

SCSI fixes for 7.3-rc4+

Mostly small driver fixes. The biggest fix is the one to the block zone
handling which might trip for real or virtual hardware if the number of
zones is > 2^32.

> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c
> index b95f187297aed..4f9a53769966f 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
[ ... ]
> @@ -7886,7 +7886,9 @@ megasas_resume(struct device *dev)
>  			goto fail_init_mfi;
>  	}
>  
> -	if (megasas_get_ctrl_info(instance) != DCMD_SUCCESS)
> +	scoped_guard(mutex, &instance->reset_mutex)
> +		rval = megasas_get_ctrl_info(instance);
> +	if (rval != DCMD_SUCCESS)

[Severity: Low]
This isn't a bug, but this function relies heavily on goto-based error
handling.

Does the introduction of a scope-based cleanup helper (scoped_guard) here
violate the cleanup subsystem guidelines?

The kernel cleanup guidelines state that scope-based cleanup helpers and
goto should not be mixed in the same function, as it can create confusing
ownership semantics.

>  		goto fail_init_mfi;
>  
>  	tasklet_init(&instance->isr_tasklet, instance->instancet->tasklet,
[ ... ]
> diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
> index 2ba244cf40ac7..54f4e7d7de02e 100644
> --- a/drivers/ufs/core/ufshcd.c
> +++ b/drivers/ufs/core/ufshcd.c
> @@ -6817,11 +6817,17 @@ static void ufshcd_err_handling_prepare(struct ufs_hba *hba)
>  	}
>  	/* Wait for ongoing ufshcd_queuecommand() calls to finish. */
>  	blk_mq_quiesce_tagset(&hba->host->tag_set);
> +	/*
> +	 * Internal commands are submitted on the pseudo SCSI device. Let them
> +	 * through so that the error handler can recover the link.
> +	 */
> +	blk_mq_unquiesce_queue(hba->host->pseudo_sdev->request_queue);

[Severity: High]
Can this sequence lead to a use-after-free on hba->host->pseudo_sdev?

If a device error triggers ufshcd_intr(), it schedules hba->eh_work.
Concurrently, the driver could be unbound, invoking ufshcd_remove().

ufshcd_remove() calls scsi_remove_host(), which destroys and frees the SCSI
devices, including hba->host->pseudo_sdev.

Because ufshcd_remove() does not cancel hba->eh_work until later in
ufshcd_hba_exit(), the error handler might execute
ufshcd_err_handling_prepare() while teardown is in progress.

Is it possible for the code to dereference hba->host->pseudo_sdev here
after it has already been freed?

>  	cancel_work_sync(&hba->eeh_work);
>  }
>  
>  static void ufshcd_err_handling_unprepare(struct ufs_hba *hba)
>  {
> +	blk_mq_quiesce_queue_nowait(hba->host->pseudo_sdev->request_queue);
>  	blk_mq_unquiesce_tagset(&hba->host->tag_set);
>  	ufshcd_release(hba);
>  	if (ufshcd_is_clkscaling_supported(hba))

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/ea8f769b49f7d1185f588cf5b9202f300c280af7.camel@HansenPartnership.com?part=1