[PATCH v3 phy-next 4/8] soc: fsl: guts: make it easier to determine on which SoC we are running

[sashiko-bot at kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Dereferencing a NULL pointer on the `soc_dev_attr` allocation error path in `fsl_guts_init()`.
--

--- Patch [4]: [PATCH v3 phy-next 4/8] soc: fsl: guts: make it easier to determine on which SoC we are running ---
commit 27fff30cda7c763b92c9fd890450416b6a304140
Author: Ioana Ciornei <ioana.ciornei at nxp.com>

soc: fsl: guts: make it easier to determine on which SoC we are running

The guts driver will need to easily determine on which SoC it's running
when it will need to perform RCW override at runtime. The guts driver
knows this already because fsl_guts_init() reads the QorIQ/Layerscape
architectural System Version Register (SVR), but it doesn't save this
for later lookups.

> diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
> index e1b3a054e681b..922560d987824 100644
> --- a/drivers/soc/fsl/guts.c
> +++ b/drivers/soc/fsl/guts.c
[ ... ]
> @@ -239,12 +274,12 @@ static int __init fsl_guts_init(void)
>  	if (!soc_dev_attr->family)
>  		goto err_nomem;
>  
> -	soc_dev_attr->soc_id = kasprintf(GFP_KERNEL, "svr:0x%08x", svr);
> +	soc_dev_attr->soc_id = kasprintf(GFP_KERNEL, "svr:0x%08x", soc.svr);
>  	if (!soc_dev_attr->soc_id)
>  		goto err_nomem;

[Severity: High]
Does jumping to err_nomem when soc_dev_attr allocation fails cause a NULL
pointer dereference?

In an earlier commit in this series ("soc: fsl: guts: add a global structure
to hold state"), the error path in fsl_guts_init() was modified to unmap
soc.dcfg_ccsr, but it seems the cleanup assumes soc_dev_attr is valid:

fsl_guts_init()
	soc_dev_attr = kzalloc_obj(*soc_dev_attr);
	if (!soc_dev_attr)
		goto err_nomem;
    ...
err_nomem:
	ret = -ENOMEM;
err:
	kfree(soc_dev_attr->family);

If the dynamic allocation for soc_dev_attr fails, wouldn't we dereference
the NULL pointer when freeing its members in the err block?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260720133642.136324-1-vladimir.oltean@nxp.com?part=4