From: sashiko-bot@kernel.org
To: "Vladimir Oltean" <vladimir.oltean@nxp.com>
Cc: robh@kernel.org, conor+dt@kernel.org, devicetree@vger.kernel.org,
olteanv@gmail.com, linux-phy@lists.infradead.org,
neil.armstrong@linaro.org, vkoul@kernel.org
Subject: Re: [PATCH v3 phy-next 3/8] soc: fsl: guts: add a central fsl_guts_read() function
Date: Mon, 20 Jul 2026 13:51:17 +0000 [thread overview]
Message-ID: <20260720135117.D11371F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260720133642.136324-4-vladimir.oltean@nxp.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Dereferencing NULL pointer 'soc_dev_attr' on the error path if its memory allocation fails.
--
--- Patch [3]: [PATCH v3 phy-next 3/8] soc: fsl: guts: add a central fsl_guts_read() function ---
commit cc1312c02ab5c2cd3fed5e2907608e44453c7816
Author: Ioana Ciornei <ioana.ciornei@nxp.com>
soc: fsl: guts: add a central fsl_guts_read() function
This commit adds a central fsl_guts_read() function that handles reading
DCFG registers based on the already determined endianness. This avoids
duplicating the if-else endianness checks across the driver.
> diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
> index a2b4c477b064b..e1b3a054e681b 100644
> --- a/drivers/soc/fsl/guts.c
> +++ b/drivers/soc/fsl/guts.c
> @@ -111,6 +111,14 @@ static struct fsl_soc_guts {
> bool little_endian;
> } soc;
>
> +static unsigned int fsl_guts_read(const void __iomem *reg)
> +{
> + if (soc.little_endian)
> + return ioread32(reg);
> +
> + return ioread32be(reg);
> +}
> +
> static const struct fsl_soc_die_attr *fsl_soc_die_match(
> u32 svr, const struct fsl_soc_die_attr *matches)
> {
[ ... ]
> @@ -209,10 +217,7 @@ static int __init fsl_guts_init(void)
> }
>
> soc.little_endian = of_property_read_bool(np, "little-endian");
> - if (soc.little_endian)
> - svr = ioread32(&soc.dcfg_ccsr->svr);
> - else
> - svr = ioread32be(&soc.dcfg_ccsr->svr);
> + svr = fsl_guts_read(&soc.dcfg_ccsr->svr);
> of_node_put(np);
>
> /* Register soc device */
[Severity: High]
Does this code trigger a NULL pointer dereference on the error path if memory
allocation for soc_dev_attr fails?
In fsl_guts_init(), if the kzalloc_obj() allocation for soc_dev_attr fails
just below this block, the code jumps to err_nomem and falls through to the
err label:
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);
kfree(soc_dev_attr->soc_id);
...
}
Since soc_dev_attr is NULL when taking this path, won't calling
kfree(soc_dev_attr->family) dereference the NULL pointer during device
initialization?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260720133642.136324-1-vladimir.oltean@nxp.com?part=3
WARNING: multiple messages have this Message-ID (diff)
From: sashiko-bot@kernel.org
To: "Vladimir Oltean" <vladimir.oltean@nxp.com>
Cc: robh@kernel.org, conor+dt@kernel.org, devicetree@vger.kernel.org,
olteanv@gmail.com, linux-phy@lists.infradead.org,
neil.armstrong@linaro.org, vkoul@kernel.org
Subject: Re: [PATCH v3 phy-next 3/8] soc: fsl: guts: add a central fsl_guts_read() function
Date: Mon, 20 Jul 2026 13:51:17 +0000 [thread overview]
Message-ID: <20260720135117.D11371F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260720133642.136324-4-vladimir.oltean@nxp.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Dereferencing NULL pointer 'soc_dev_attr' on the error path if its memory allocation fails.
--
--- Patch [3]: [PATCH v3 phy-next 3/8] soc: fsl: guts: add a central fsl_guts_read() function ---
commit cc1312c02ab5c2cd3fed5e2907608e44453c7816
Author: Ioana Ciornei <ioana.ciornei@nxp.com>
soc: fsl: guts: add a central fsl_guts_read() function
This commit adds a central fsl_guts_read() function that handles reading
DCFG registers based on the already determined endianness. This avoids
duplicating the if-else endianness checks across the driver.
> diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
> index a2b4c477b064b..e1b3a054e681b 100644
> --- a/drivers/soc/fsl/guts.c
> +++ b/drivers/soc/fsl/guts.c
> @@ -111,6 +111,14 @@ static struct fsl_soc_guts {
> bool little_endian;
> } soc;
>
> +static unsigned int fsl_guts_read(const void __iomem *reg)
> +{
> + if (soc.little_endian)
> + return ioread32(reg);
> +
> + return ioread32be(reg);
> +}
> +
> static const struct fsl_soc_die_attr *fsl_soc_die_match(
> u32 svr, const struct fsl_soc_die_attr *matches)
> {
[ ... ]
> @@ -209,10 +217,7 @@ static int __init fsl_guts_init(void)
> }
>
> soc.little_endian = of_property_read_bool(np, "little-endian");
> - if (soc.little_endian)
> - svr = ioread32(&soc.dcfg_ccsr->svr);
> - else
> - svr = ioread32be(&soc.dcfg_ccsr->svr);
> + svr = fsl_guts_read(&soc.dcfg_ccsr->svr);
> of_node_put(np);
>
> /* Register soc device */
[Severity: High]
Does this code trigger a NULL pointer dereference on the error path if memory
allocation for soc_dev_attr fails?
In fsl_guts_init(), if the kzalloc_obj() allocation for soc_dev_attr fails
just below this block, the code jumps to err_nomem and falls through to the
err label:
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);
kfree(soc_dev_attr->soc_id);
...
}
Since soc_dev_attr is NULL when taking this path, won't calling
kfree(soc_dev_attr->family) dereference the NULL pointer during device
initialization?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260720133642.136324-1-vladimir.oltean@nxp.com?part=3
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
next prev parent reply other threads:[~2026-07-20 13:51 UTC|newest]
Thread overview: 44+ 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 ` 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 ` 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:36 ` Vladimir Oltean
2026-07-20 13:50 ` sashiko-bot
2026-07-20 13:50 ` sashiko-bot
2026-07-20 14:01 ` Vladimir Oltean
2026-07-20 14:01 ` Vladimir Oltean
2026-07-20 14:57 ` Vladimir Oltean
2026-07-20 14:57 ` Vladimir Oltean
2026-07-21 8:44 ` Michael Walle
2026-07-21 8:44 ` Michael Walle
2026-07-21 10:43 ` Vladimir Oltean
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:36 ` Vladimir Oltean
2026-07-20 13:51 ` sashiko-bot [this message]
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:36 ` Vladimir Oltean
2026-07-20 13:53 ` sashiko-bot
2026-07-20 13:53 ` sashiko-bot
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:36 ` Vladimir Oltean
2026-07-20 13:58 ` sashiko-bot
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:36 ` Vladimir Oltean
2026-07-20 13:57 ` sashiko-bot
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 13:36 ` Vladimir Oltean
2026-07-20 14:03 ` sashiko-bot
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 13:36 ` Vladimir Oltean
2026-07-20 14:13 ` sashiko-bot
2026-07-20 14:13 ` sashiko-bot
2026-07-20 16:34 ` Vinod Koul
2026-07-20 16:34 ` Vinod Koul
2026-07-20 20:12 ` Vladimir Oltean
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=20260720135117.D11371F00A3A@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.