[PATCH] phy: renesas: rcar-gen2: Return -EINVAL for out-of-range channel reg

[sashiko-bot at kernel.org]

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

Pre-existing issues:
- [High] Calling explicit `of_node_put(np)` inside a `for_each_child_of_node_scoped()` loop causes a double-free on the error path.
- [High] Storing a device node pointer in `channel->of_node` without incrementing its reference count leads to a dangling pointer.
- [High] `rcar_gen2_phy_init()` ignores the return value of `clk_prepare_enable()`, potentially accessing unclocked hardware.
- [High] Dynamic device tree node addition between node count and iteration causes out-of-bounds array access.
--

--- Patch [1]: [PATCH] phy: renesas: rcar-gen2: Return -EINVAL for out-of-range channel reg ---
commit 1182e2b5f6437e08233213f334dad41e6af137fa
Author: Felix Gu <ustc.gu at gmail.com>

phy: renesas: rcar-gen2: Return -EINVAL for out-of-range channel reg

When of_property_read_u32() succeeds but channel_num exceeds
data->num_channels, the probe function erroneously reports success despite 
no PHY provider being registered. This commit fixes the issue by returning 
-EINVAL in that specific case.

> diff --git a/drivers/phy/renesas/phy-rcar-gen2.c b/drivers/phy/renesas/phy-rcar-gen2.c
> index 6c671254c6258..f0858d8cc7056 100644
> --- a/drivers/phy/renesas/phy-rcar-gen2.c
> +++ b/drivers/phy/renesas/phy-rcar-gen2.c
> @@ -390,7 +390,7 @@ static int rcar_gen2_phy_probe(struct platform_device *pdev)
>  		error = of_property_read_u32(np, "reg", &channel_num);
>  		if (error || channel_num >= data->num_channels) {
>  			dev_err(dev, "Invalid \"reg\" property\n");
> -			return error;
> +			return error ?: -EINVAL;
>  		}
>  		channel->select_mask = select_mask[channel_num];
>  

[Severity: High]
This is a pre-existing issue, but could the explicit of_node_put(np) inside
for_each_child_of_node_scoped() cause a double-free?

The scoped iterator already automatically cleans up the node reference on
early returns. Is it possible that this explicit put corrupts the reference
count:

drivers/phy/renesas/phy-rcar-gen2.c:rcar_gen2_phy_probe() {
    ...
		for (n = 0; n < PHYS_PER_CHANNEL; n++) {
    ...
			phy->phy = devm_phy_create(dev, NULL,
						   data->gen2_phy_ops);
			if (IS_ERR(phy->phy)) {
				dev_err(dev, "Failed to create PHY\n");
				of_node_put(np);
				return PTR_ERR(phy->phy);
			}
    ...
}


[Severity: High]
This is a pre-existing issue, but I am wondering if this leaves a dangling
pointer in channel->of_node?

The scoped iterator automatically drops the reference to np when it
advances or terminates, but the pointer is saved without acquiring a
reference via of_node_get():

drivers/phy/renesas/phy-rcar-gen2.c:rcar_gen2_phy_probe() {
    ...
	for_each_child_of_node_scoped(dev->of_node, np) {
		struct rcar_gen2_channel *channel = drv->channels + i;
		...
		channel->of_node = np;
    ...
}

Can this unreferenced pointer later be used for comparison and cause
incorrect PHY instances to be returned if the device tree node is
dynamically freed?

drivers/phy/renesas/phy-rcar-gen2.c:rcar_gen2_phy_xlate() {
    ...
	for (i = 0; i < drv->num_channels; i++) {
		if (np == drv->channels[i].of_node)
			break;
	}
    ...
}


[Severity: High]
This isn't a bug introduced by this patch, but it looks like
rcar_gen2_phy_init() ignores the return value of clk_prepare_enable().

If the clock fails to enable, the driver proceeds to acquire a spinlock
and write to the USBHS_UGCTRL2 hardware register:

drivers/phy/renesas/phy-rcar-gen2.c:rcar_gen2_phy_init() {
    ...
	clk_prepare_enable(drv->clk);

	spin_lock_irqsave(&drv->lock, flags);
	ugctrl2 = readl(drv->base + USBHS_UGCTRL2);
    ...
}

Would this access unclocked hardware and result in a fatal bus error?


[Severity: High]
This isn't a bug introduced by this patch, but might there be an
out-of-bounds array access here if child nodes are dynamically added?

The probe function allocates the drv->channels array exactly to the
current child count, but iterates over potentially modified children using
an unbounded index i to write to drv->channels + i:

drivers/phy/renesas/phy-rcar-gen2.c:rcar_gen2_phy_probe() {
    ...
	drv->num_channels = of_get_child_count(dev->of_node);
	drv->channels = devm_kcalloc(dev, drv->num_channels,
				     sizeof(struct rcar_gen2_channel),
				     GFP_KERNEL);
    ...
	for_each_child_of_node_scoped(dev->of_node, np) {
		struct rcar_gen2_channel *channel = drv->channels + i;
        ...
		i++;
	}
    ...
}

Could a device tree overlay added between the count and the loop cause a
heap buffer overflow?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260803-rcar-gen2-1-v1-1-4796ea6e76d8@gmail.com?part=1