From: sashiko-bot@kernel.org
To: "Vladimir Oltean" <vladimir.oltean@nxp.com>
Cc: olteanv@gmail.com, linux-phy@lists.infradead.org,
devicetree@vger.kernel.org, robh@kernel.org, conor+dt@kernel.org,
vkoul@kernel.org, neil.armstrong@linaro.org
Subject: Re: [PATCH v3 phy-next 4/8] soc: fsl: guts: make it easier to determine on which SoC we are running
Date: Mon, 20 Jul 2026 13:53:35 +0000 [thread overview]
Message-ID: <20260720135336.2455F1F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260720133642.136324-5-vladimir.oltean@nxp.com>
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@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
next prev parent reply other threads:[~2026-07-20 13:53 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-20 13:36 [PATCH v3 phy-next 0/8] RCW override for 10G Lynx dynamic protocol reconfiguration Vladimir Oltean
2026-07-20 13:36 ` [PATCH v3 phy-next 1/8] soc: fsl: guts: use a macro to encode the DCFG CCSR space Vladimir Oltean
2026-07-20 13:36 ` [PATCH v3 phy-next 2/8] soc: fsl: guts: add a global structure to hold state Vladimir Oltean
2026-07-20 13:50 ` sashiko-bot
2026-07-20 14:01 ` Vladimir Oltean
2026-07-20 14:57 ` Vladimir Oltean
2026-07-21 8:44 ` Michael Walle
2026-07-21 10:43 ` Vladimir Oltean
2026-07-20 13:36 ` [PATCH v3 phy-next 3/8] soc: fsl: guts: add a central fsl_guts_read() function Vladimir Oltean
2026-07-20 13:51 ` sashiko-bot
2026-07-20 13:36 ` [PATCH v3 phy-next 4/8] soc: fsl: guts: make it easier to determine on which SoC we are running Vladimir Oltean
2026-07-20 13:53 ` sashiko-bot [this message]
2026-07-20 13:36 ` [PATCH v3 phy-next 5/8] soc: fsl: guts: make fsl_soc_data available after fsl_guts_init() Vladimir Oltean
2026-07-20 13:58 ` sashiko-bot
2026-07-20 13:36 ` [PATCH v3 phy-next 6/8] dt-bindings: fsl: layerscape-dcfg: define DCFG_DCSR region Vladimir Oltean
2026-07-20 13:57 ` sashiko-bot
2026-07-20 13:36 ` [PATCH v3 phy-next 7/8] soc: fsl: guts: implement the RCW override procedure Vladimir Oltean
2026-07-20 14:03 ` sashiko-bot
2026-07-20 13:36 ` [PATCH v3 phy-next 8/8] phy: lynx-10g: use RCW override procedure for dynamic protocol change Vladimir Oltean
2026-07-20 14:13 ` sashiko-bot
2026-07-20 16:34 ` Vinod Koul
2026-07-20 20:12 ` Vladimir Oltean
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260720135336.2455F1F00A3A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=neil.armstrong@linaro.org \
--cc=olteanv@gmail.com \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=vkoul@kernel.org \
--cc=vladimir.oltean@nxp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox