[PATCH v2 1/3] phy: renesas: rcar-gen2: Fix double of_node_put on phy creation failure

sashiko-bot at kernel.org sashiko-bot at kernel.org
Tue Aug 4 08:38:00 PDT 2026


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

Pre-existing issues:
- [High] Missing reference count increment for device node leads to a dangling pointer.
- [High] TOCTOU race condition between child count and iteration leads to out-of-bounds array write.
--

--- Patch [1]: [PATCH v2 1/3] phy: renesas: rcar-gen2: Fix double of_node_put on phy creation failure ---
commit 047745265c7b61da44949752ecc277b2156237a3
Author: Felix Gu <ustc.gu at gmail.com>

phy: renesas: rcar-gen2: Fix double of_node_put on phy creation failure

This commit fixes a double of_node_put() issue in the error path of
devm_phy_create(). The scoped iterator for_each_child_of_node_scoped()
already handles dropping the node reference, so the explicit of_node_put()
was redundant.

> diff --git a/drivers/phy/renesas/phy-rcar-gen2.c b/drivers/phy/renesas/phy-rcar-gen2.c
> index 6c671254c6258..5a272e25e051c 100644
> --- a/drivers/phy/renesas/phy-rcar-gen2.c
> +++ b/drivers/phy/renesas/phy-rcar-gen2.c
> @@ -405,7 +405,6 @@ static int rcar_gen2_phy_probe(struct platform_device *pdev)
>  						   data->gen2_phy_ops);
>  			if (IS_ERR(phy->phy)) {
>  				dev_err(dev, "Failed to create PHY\n");

[Severity: High]
This is a pre-existing issue, but does this code leave a dangling pointer
when saving the node?

Looking at rcar_gen2_phy_probe(), we save np to channel->of_node:

	for_each_child_of_node_scoped(dev->of_node, np) {
		struct rcar_gen2_channel *channel = drv->channels + i;
		...
		channel->of_node = np;

Because for_each_child_of_node_scoped() automatically drops the reference on
the node when advancing or exiting, channel->of_node becomes a dangling pointer.

Later in rcar_gen2_phy_xlate(), this potentially dangling pointer is
used for comparison:

	if (np == drv->channels[i].of_node)

Could this falsely match a newly allocated node due to pointer aliasing if a
DT overlay is applied and removed? Should we call of_node_get() before
saving it to channel->of_node?


[Severity: High]
This is also a pre-existing issue, but is there a potential out-of-bounds write
if the number of child nodes changes?

Earlier in rcar_gen2_phy_probe(), the driver allocates the channels array based
on the child count:

	drv->num_channels = of_get_child_count(dev->of_node);
	drv->channels = devm_kcalloc(dev, drv->num_channels, ...);

Then it iterates over the children and increments i:

	for_each_child_of_node_scoped(dev->of_node, np) {
		struct rcar_gen2_channel *channel = drv->channels + i;
		...
		i++;
	}

If child nodes are added dynamically (e.g., via a DT overlay) between the call
to of_get_child_count() and the for_each_child_of_node_scoped() loop, could i
exceed drv->num_channels and cause an out-of-bounds write when accessing
drv->channels + i?

> -				of_node_put(np);
>  				return PTR_ERR(phy->phy);
>  			}
>  			phy_set_drvdata(phy->phy, phy);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260804-rcar-gen2-v2-0-829cb84112ca@gmail.com?part=1



More information about the linux-phy mailing list