* [PATCH] phy: renesas: rcar-gen2: Return -EINVAL for out-of-range channel reg
@ 2026-08-03 13:07 ` Felix Gu
0 siblings, 0 replies; 7+ messages in thread
From: Felix Gu @ 2026-08-03 13:07 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Geert Uytterhoeven, Magnus Damm,
Ulrich Hecht, Wolfram Sang, Biju Das, Yoshihiro Shimoda,
Sergei Shtylyov
Cc: Kishon Vijay Abraham I, linux-phy, linux-renesas-soc,
linux-kernel, Felix Gu
When of_property_read_u32() succeeds but channel_num exceeds
data->num_channels, rcar_gen2_phy_probe() returns error which is 0,
so probe reports success even though no PHY provider is registered.
Return -EINVAL in that case.
Fixes: 1233f59f745b ("phy: Renesas R-Car Gen2 PHY driver")
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
---
drivers/phy/renesas/phy-rcar-gen2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/phy/renesas/phy-rcar-gen2.c b/drivers/phy/renesas/phy-rcar-gen2.c
index 6c671254c625..f0858d8cc705 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];
---
base-commit: 415606a7be939835db9b0d6b711887586646346d
change-id: 20260803-rcar-gen2-1-98f440b28b35
Best regards,
--
Felix Gu <ustc.gu@gmail.com>
^ permalink raw reply related [flat|nested] 7+ messages in thread* Re: [PATCH] phy: renesas: rcar-gen2: Return -EINVAL for out-of-range channel reg
2026-08-03 13:07 ` Felix Gu
(?)
@ 2026-08-03 13:18 ` sashiko-bot
-1 siblings, 0 replies; 7+ messages in thread
From: sashiko-bot @ 2026-08-03 13:18 UTC (permalink / raw)
To: Felix Gu; +Cc: vkoul, neil.armstrong, wsa+renesas, olteanv, linux-phy
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@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
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 7+ messages in thread* RE: [PATCH] phy: renesas: rcar-gen2: Return -EINVAL for out-of-range channel reg
2026-08-03 13:07 ` Felix Gu
@ 2026-08-03 13:26 ` Biju Das
-1 siblings, 0 replies; 7+ messages in thread
From: Biju Das @ 2026-08-03 13:26 UTC (permalink / raw)
To: Felix Gu, Vinod Koul, Neil Armstrong, Geert Uytterhoeven,
magnus.damm, Ulrich Hecht, wsa+renesas, Yoshihiro Shimoda,
Sergei Shtylyov
Cc: Kishon Vijay Abraham I, linux-phy@lists.infradead.org,
linux-renesas-soc@vger.kernel.org, linux-kernel@vger.kernel.org
Hi Felix Gu,
Thanks for the patch.
> -----Original Message-----
> From: Felix Gu <ustc.gu@gmail.com>
> Sent: 03 August 2026 14:07
> Subject: [PATCH] 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, rcar_gen2_phy_probe() returns error which is 0,
> so probe reports success even though no PHY provider is registered.
>
> Return -EINVAL in that case.
>
> Fixes: 1233f59f745b ("phy: Renesas R-Car Gen2 PHY driver")
> Signed-off-by: Felix Gu <ustc.gu@gmail.com>
> ---
> drivers/phy/renesas/phy-rcar-gen2.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/phy/renesas/phy-rcar-gen2.c b/drivers/phy/renesas/phy-rcar-gen2.c
> index 6c671254c625..f0858d8cc705 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;
Can we use dev_error_probe() here as well??
Cheers,
Biju
> }
> channel->select_mask = select_mask[channel_num];
>
>
> ---
> base-commit: 415606a7be939835db9b0d6b711887586646346d
> change-id: 20260803-rcar-gen2-1-98f440b28b35
>
> Best regards,
> --
> Felix Gu <ustc.gu@gmail.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 7+ messages in thread* RE: [PATCH] phy: renesas: rcar-gen2: Return -EINVAL for out-of-range channel reg
@ 2026-08-03 13:26 ` Biju Das
0 siblings, 0 replies; 7+ messages in thread
From: Biju Das @ 2026-08-03 13:26 UTC (permalink / raw)
To: Felix Gu, Vinod Koul, Neil Armstrong, Geert Uytterhoeven,
magnus.damm, Ulrich Hecht, wsa+renesas, Yoshihiro Shimoda,
Sergei Shtylyov
Cc: Kishon Vijay Abraham I, linux-phy@lists.infradead.org,
linux-renesas-soc@vger.kernel.org, linux-kernel@vger.kernel.org
Hi Felix Gu,
Thanks for the patch.
> -----Original Message-----
> From: Felix Gu <ustc.gu@gmail.com>
> Sent: 03 August 2026 14:07
> Subject: [PATCH] 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, rcar_gen2_phy_probe() returns error which is 0,
> so probe reports success even though no PHY provider is registered.
>
> Return -EINVAL in that case.
>
> Fixes: 1233f59f745b ("phy: Renesas R-Car Gen2 PHY driver")
> Signed-off-by: Felix Gu <ustc.gu@gmail.com>
> ---
> drivers/phy/renesas/phy-rcar-gen2.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/phy/renesas/phy-rcar-gen2.c b/drivers/phy/renesas/phy-rcar-gen2.c
> index 6c671254c625..f0858d8cc705 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;
Can we use dev_error_probe() here as well??
Cheers,
Biju
> }
> channel->select_mask = select_mask[channel_num];
>
>
> ---
> base-commit: 415606a7be939835db9b0d6b711887586646346d
> change-id: 20260803-rcar-gen2-1-98f440b28b35
>
> Best regards,
> --
> Felix Gu <ustc.gu@gmail.com>
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCH] phy: renesas: rcar-gen2: Return -EINVAL for out-of-range channel reg
2026-08-03 13:26 ` Biju Das
@ 2026-08-04 14:39 ` Felix Gu
-1 siblings, 0 replies; 7+ messages in thread
From: Felix Gu @ 2026-08-04 14:39 UTC (permalink / raw)
To: Biju Das
Cc: Vinod Koul, Neil Armstrong, Geert Uytterhoeven, magnus.damm,
Ulrich Hecht, wsa+renesas, Yoshihiro Shimoda, Sergei Shtylyov,
Kishon Vijay Abraham I, linux-phy@lists.infradead.org,
linux-renesas-soc@vger.kernel.org, linux-kernel@vger.kernel.org
On Mon, Aug 3, 2026 at 9:26 PM Biju Das <biju.das.jz@bp.renesas.com> wrote:
>
> Hi Felix Gu,
>
> Can we use dev_error_probe() here as well??
>
> Cheers,
> Biju
>
Hi Biju,
It may be better to convert to use dev_err_probe in the probe function
with a new patch.
I will send out one later.
Best regards,
Felix
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] phy: renesas: rcar-gen2: Return -EINVAL for out-of-range channel reg
@ 2026-08-04 14:39 ` Felix Gu
0 siblings, 0 replies; 7+ messages in thread
From: Felix Gu @ 2026-08-04 14:39 UTC (permalink / raw)
To: Biju Das
Cc: Vinod Koul, Neil Armstrong, Geert Uytterhoeven, magnus.damm,
Ulrich Hecht, wsa+renesas, Yoshihiro Shimoda, Sergei Shtylyov,
Kishon Vijay Abraham I, linux-phy@lists.infradead.org,
linux-renesas-soc@vger.kernel.org, linux-kernel@vger.kernel.org
On Mon, Aug 3, 2026 at 9:26 PM Biju Das <biju.das.jz@bp.renesas.com> wrote:
>
> Hi Felix Gu,
>
> Can we use dev_error_probe() here as well??
>
> Cheers,
> Biju
>
Hi Biju,
It may be better to convert to use dev_err_probe in the probe function
with a new patch.
I will send out one later.
Best regards,
Felix
^ permalink raw reply [flat|nested] 7+ messages in thread