Re: [PATCH] scsi: ufs: core: Initialize hba->rpmbs list in ufshcd

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but a circular dependency between the parent UFS RPMB device and its child RPMB device prevents both from being unregistered and freed.
- [High] This problem wasn't introduced by this patch, but the `struct ufs_rpmb_dev` embeds a `struct device` and is incorrectly allocated using `devm_kzalloc()`, violating the Linux device model and risking a Use-After-Free on unbind.
--

--- Patch [1]: [PATCH] scsi: ufs: core: Initialize hba->rpmbs list in ufshcd ---
commit b69c44ec9068da0584fce2f43d2e235ffbfe2675
Author: Ao Sun <ao.sun@transsion.com>

scsi: ufs: core: Initialize hba->rpmbs list in ufshcd
    
Initialize the hba->rpmbs list in ufshcd_alloc_host() to prevent NULL
pointer dereference in the device teardown path if ufs_rpmb_probe()
fails.

> diff --git a/drivers/ufs/core/ufs-rpmb.c b/drivers/ufs/core/ufs-rpmb.c
> index ffad049872b9a..62120dc2e9da7 100644
> --- a/drivers/ufs/core/ufs-rpmb.c
> +++ b/drivers/ufs/core/ufs-rpmb.c
> @@ -152,8 +152,6 @@ int ufs_rpmb_probe(struct ufs_hba *hba)
>  		return -EINVAL;
>  	}
>  
> -	INIT_LIST_HEAD(&hba->rpmbs);
> -

[Severity: High]
This isn't a bug introduced by this patch, but is it safe to allocate
ufs_rpmb using devm_kzalloc() when it embeds a struct device?

The ufs_rpmb structure is tied to the host device's devres lifecycle:

ufs_rpmb_probe() {
        ...
        ufs_rpmb = devm_kzalloc(hba->dev, sizeof(*ufs_rpmb), GFP_KERNEL);
        ...
}

When the host controller unbinds, devres will free this memory. However,
if a userspace process holds an open file descriptor to the sysfs
attributes of ufs_rpmb->dev, the kobject reference count remains elevated.

When userspace later closes the file, the driver core will drop the final
reference and invoke ufs_rpmb_device_release(), which will access the
already-freed ufs_rpmb_dev structure.

Could this result in a use-after-free on unbind?


[Severity: High]
This isn't a bug introduced by this patch, but does the error path in
ufs_rpmb_probe() fully clean up the registered RPMB devices?

If device_unregister() is called on ufs_rpmb->dev during probe error or
unbind, the parent device is unregistered. However, rpmb_dev_register()
creates a child device that holds a reference to this parent.

Because the child holds a reference, the parent's reference count will
not drop to zero, preventing its release callback from ever running:

ufs_rpmb_device_release() {
        ...
        rpmb_dev_unregister(ufs_rpmb->rdev);
        ...
}

Since rpmb_dev_unregister() is called inside that release callback, neither
device gets fully unregistered.

Does this create a circular dependency that leaks device structures and
sysfs entries?

>  	struct rpmb_descr descr = {
>  		.type = RPMB_TYPE_UFS,
>  		.route_frames = ufs_rpmb_route_frames,

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260723034440.217-1-ao.sun@transsion.com?part=1