Re: [PATCH] soc: imx9: devm_kasprintf error handling

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Missing unregister mechanism for the SoC device causes a Use-After-Free if the driver is unbound via sysfs.
--

commit 84c9267e8e5f768b0aa5bc1444220a55eb7de229
Author: Griffin Kroah-Hartman <griffin@kroah.com>

soc: imx9: devm_kasprintf error handling

This commit adds error handling to devm_kasprintf calls in imx9_soc_probe(), 
ensuring that memory allocation failures return -ENOMEM rather than silently 
continuing.

> diff --git a/drivers/soc/imx/soc-imx9.c b/drivers/soc/imx/soc-imx9.c
> index 58eef7d4f9089..23b54b7d75027 100644
> --- a/drivers/soc/imx/soc-imx9.c
> +++ b/drivers/soc/imx/soc-imx9.c

[ ... ]

> @@ -52,11 +54,18 @@ static int imx9_soc_probe(struct platform_device *pdev)
>  	rev_minor = SOC_REV_MINOR(res.a1);
>  
>  	attr->soc_id = devm_kasprintf(dev, GFP_KERNEL, "i.MX%2x", soc_id);
> +	if (!attr->soc_id)
> +		return -ENOMEM;
> +
>  	attr->revision = devm_kasprintf(dev, GFP_KERNEL, "%d.%d", rev_major, rev_minor);
> +	if (!attr->revision)
> +		return -ENOMEM;
>  
>  	uid127_64 = res.a2;
>  	uid63_0 = res.a3;
>  	attr->serial_number = devm_kasprintf(dev, GFP_KERNEL, "%016llx%016llx", uid127_64, uid63_0);
> +	if (!attr->serial_number)
> +		return -ENOMEM;
>  
>  	sdev = soc_device_register(attr);
>  	if (IS_ERR(sdev))
>  		return dev_err_probe(dev, PTR_ERR(sdev),
>  				     "%s failed to register SoC as a device\n", __func__);
>  
>  	return 0;
>  }

[Severity: High]
This is a pre-existing issue, but does imx9_soc_probe() lack a way to
unregister the soc_device on driver unbind?

If the imx9-soc driver is unbound via sysfs, the driver core will call
devres_release_all() and free the devm-managed attr structure, along with the
strings allocated by devm_kasprintf().

Because soc_device_unregister() is never called to complement
soc_device_register(), the soc_device remains active in the system.

Could this lead to a use-after-free if a user later reads the soc_device
sysfs attributes (like /sys/devices/soc0/family) which reference the freed
attr memory?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/2026070610-regime-badge-e99b@gregkh?part=1