Re: [PATCH v4 2/3] scsi: ufs: rpmb: Decouple device lifecycle from devres to avoid UAF

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Module Reference Leak / Unload Deadlock
--

commit c2fd812022915196c82ed205c8c33614922be2b5
Author: Stanley Jhu <stanleyjhu@google.com>

scsi: ufs: rpmb: Decouple device lifecycle from devres to avoid UAF

This commit addresses a use-after-free issue by tying the ufs_rpmb_dev
memory to its reference count instead of devres. It pins the SCSI WLUN
during probe, cleans up properly during release to break the lifecycle
cycle, and rejects requests once the WLUN is offline.

> diff --git a/drivers/ufs/core/ufs-rpmb.c b/drivers/ufs/core/ufs-rpmb.c
> index 783ecfc7581d7..373b60aba9166 100644
> --- a/drivers/ufs/core/ufs-rpmb.c
> +++ b/drivers/ufs/core/ufs-rpmb.c
[ ... ]
> @@ -177,25 +186,28 @@ int ufs_rpmb_probe(struct ufs_hba *hba)
[ ... ]
>  		ufs_rpmb = kzalloc_obj(*ufs_rpmb);
>  		if (!ufs_rpmb) {
>  			ret = -ENOMEM;
>  			goto err_out;
>  		}
>  
> -		ufs_rpmb->hba = hba;
> -		ufs_rpmb->dev.parent = &hba->ufs_rpmb_wlun->sdev_gendev;
> +		INIT_LIST_HEAD(&ufs_rpmb->node);
> +
> +		ret = scsi_device_get(sdev);

[Severity: Medium]
Does this code introduce a module reference leak that prevents driver unloading?

When ufs_rpmb_probe() calls scsi_device_get(), the following call chain occurs:

ufs_rpmb_probe()
  scsi_device_get(sdev)
    try_module_get(sdev->host->hostt->module)

Since this is called during the driver's probe sequence, and the SCSI host
template module is likely this exact same module (ufshcd-core), it ends up
taking a reference on itself. 

Because the reference won't be dropped until the device is released, and the
device won't be released while the module is held active, doesn't this create
a lifecycle deadlock where rmmod will permanently fail with -EBUSY?

> +		if (ret) {
> +			kfree(ufs_rpmb);
> +			goto err_out;
> +		}
> +
> +		ufs_rpmb->sdev = sdev;
> +		ufs_rpmb->region_id = region;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260913033633.3159296-1-stanleyjhu@google.com?part=2