All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Chaoyi Chen" <kernel@airkyi.com>
Cc: dri-devel@lists.freedesktop.org, neil.armstrong@linaro.org,
	linux-phy@lists.infradead.org, vkoul@kernel.org,
	olteanv@gmail.com
Subject: Re: [PATCH v7 5/7] phy: rockchip: phy-rockchip-typec: Add DRM AUX bridge
Date: Fri, 28 Aug 2026 09:01:22 +0000	[thread overview]
Message-ID: <20260828090123.5F35D1F00A3D@smtp.kernel.org> (raw)
In-Reply-To: <20260828084737.565-6-kernel@airkyi.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Double-free and Use-After-Free of OF Node Reference
- [Medium] Initialization Ordering and Error Masking
--

commit 0733fab98743300c9bca39a083f1a901d4ff8cda
Author: Chaoyi Chen <chaoyi.chen@rock-chips.com>

phy: rockchip: phy-rockchip-typec: Add DRM AUX bridge

Using the DRM_AUX_BRIDGE helper to create the transparent DRM bridge device.

> diff --git a/drivers/phy/rockchip/phy-rockchip-typec.c b/drivers/phy/rockchip/phy-rockchip-typec.c
> index d9701b6106d55..48070b50416e5 100644
> --- a/drivers/phy/rockchip/phy-rockchip-typec.c
> +++ b/drivers/phy/rockchip/phy-rockchip-typec.c
[ ... ]
> @@ -1162,16 +1163,24 @@ static int rockchip_typec_phy_probe(struct platform_device *pdev)
>  
>  	for_each_available_child_of_node(np, child_np) {
>  		struct phy *phy;
> +		ret = 0;
>  
> -		if (of_node_name_eq(child_np, "dp-port"))
> +		if (of_node_name_eq(child_np, "dp-port")) {
>  			phy = devm_phy_create(dev, child_np,
>  					      &rockchip_dp_phy_ops);
> -		else if (of_node_name_eq(child_np, "usb3-port"))
> +			ret = drm_aux_bridge_register_from_node(dev, child_np);

[Severity: High]
Does this code cause a double-free of the OF node reference?

Since child_np is the loop iterator in for_each_available_child_of_node(),
its reference is automatically dropped when advancing to the next iteration.
However, drm_aux_bridge_register_from_node() assigns the OF node to the
auxiliary device without incrementing the reference count, and drops a
reference in its error paths and release function. 

Will this lead to a use-after-free when the loop iterator automatically drops
the reference, leaving the registered bridge pointing to a freed device node?

[Severity: Medium]
Also, does this sequence mask errors from devm_phy_create()?

The result of devm_phy_create() is not checked before calling
drm_aux_bridge_register_from_node(). If devm_phy_create() returns an error
pointer (such as -EPROBE_DEFER) and drm_aux_bridge_register_from_node()
fails, the original error will be permanently lost when returning 'ret'
below.

Additionally, if devm_phy_create() fails but bridge registration succeeds,
an auxiliary device is registered only to be immediately unregistered via
devres when returning PTR_ERR(phy) shortly after. Could this be avoided
by checking IS_ERR(phy) before registering the bridge?

> +		} else if (of_node_name_eq(child_np, "usb3-port"))
>  			phy = devm_phy_create(dev, child_np,
>  					      &rockchip_usb3_phy_ops);
>  		else
>  			continue;
>  
> +		if (ret) {
> +			pm_runtime_disable(dev);
> +			of_node_put(child_np);

[Severity: High]
Since drm_aux_bridge_register_from_node() already dropped the OF node
reference on its internal failure path, will calling of_node_put() here
cause an immediate double-free?

> +			return ret;
> +		}
> +
>  		if (IS_ERR(phy)) {
>  			dev_err(dev, "failed to create phy: %pOFn\n",
>  				child_np);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260828084737.565-1-kernel@airkyi.com?part=5

WARNING: multiple messages have this Message-ID (diff)
From: sashiko-bot@kernel.org
To: "Chaoyi Chen" <kernel@airkyi.com>
Cc: dri-devel@lists.freedesktop.org, neil.armstrong@linaro.org,
	linux-phy@lists.infradead.org, vkoul@kernel.org,
	olteanv@gmail.com
Subject: Re: [PATCH v7 5/7] phy: rockchip: phy-rockchip-typec: Add DRM AUX bridge
Date: Fri, 28 Aug 2026 09:01:22 +0000	[thread overview]
Message-ID: <20260828090123.5F35D1F00A3D@smtp.kernel.org> (raw)
In-Reply-To: <20260828084737.565-6-kernel@airkyi.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Double-free and Use-After-Free of OF Node Reference
- [Medium] Initialization Ordering and Error Masking
--

commit 0733fab98743300c9bca39a083f1a901d4ff8cda
Author: Chaoyi Chen <chaoyi.chen@rock-chips.com>

phy: rockchip: phy-rockchip-typec: Add DRM AUX bridge

Using the DRM_AUX_BRIDGE helper to create the transparent DRM bridge device.

> diff --git a/drivers/phy/rockchip/phy-rockchip-typec.c b/drivers/phy/rockchip/phy-rockchip-typec.c
> index d9701b6106d55..48070b50416e5 100644
> --- a/drivers/phy/rockchip/phy-rockchip-typec.c
> +++ b/drivers/phy/rockchip/phy-rockchip-typec.c
[ ... ]
> @@ -1162,16 +1163,24 @@ static int rockchip_typec_phy_probe(struct platform_device *pdev)
>  
>  	for_each_available_child_of_node(np, child_np) {
>  		struct phy *phy;
> +		ret = 0;
>  
> -		if (of_node_name_eq(child_np, "dp-port"))
> +		if (of_node_name_eq(child_np, "dp-port")) {
>  			phy = devm_phy_create(dev, child_np,
>  					      &rockchip_dp_phy_ops);
> -		else if (of_node_name_eq(child_np, "usb3-port"))
> +			ret = drm_aux_bridge_register_from_node(dev, child_np);

[Severity: High]
Does this code cause a double-free of the OF node reference?

Since child_np is the loop iterator in for_each_available_child_of_node(),
its reference is automatically dropped when advancing to the next iteration.
However, drm_aux_bridge_register_from_node() assigns the OF node to the
auxiliary device without incrementing the reference count, and drops a
reference in its error paths and release function. 

Will this lead to a use-after-free when the loop iterator automatically drops
the reference, leaving the registered bridge pointing to a freed device node?

[Severity: Medium]
Also, does this sequence mask errors from devm_phy_create()?

The result of devm_phy_create() is not checked before calling
drm_aux_bridge_register_from_node(). If devm_phy_create() returns an error
pointer (such as -EPROBE_DEFER) and drm_aux_bridge_register_from_node()
fails, the original error will be permanently lost when returning 'ret'
below.

Additionally, if devm_phy_create() fails but bridge registration succeeds,
an auxiliary device is registered only to be immediately unregistered via
devres when returning PTR_ERR(phy) shortly after. Could this be avoided
by checking IS_ERR(phy) before registering the bridge?

> +		} else if (of_node_name_eq(child_np, "usb3-port"))
>  			phy = devm_phy_create(dev, child_np,
>  					      &rockchip_usb3_phy_ops);
>  		else
>  			continue;
>  
> +		if (ret) {
> +			pm_runtime_disable(dev);
> +			of_node_put(child_np);

[Severity: High]
Since drm_aux_bridge_register_from_node() already dropped the OF node
reference on its internal failure path, will calling of_node_put() here
cause an immediate double-free?

> +			return ret;
> +		}
> +
>  		if (IS_ERR(phy)) {
>  			dev_err(dev, "failed to create phy: %pOFn\n",
>  				child_np);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260828084737.565-1-kernel@airkyi.com?part=5

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

  reply	other threads:[~2026-08-28  9:01 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-28  8:47 [PATCH v7 0/7] drm/bridge: Implement generic USB Type-C DP HPD bridge Chaoyi Chen
2026-08-28  8:47 ` Chaoyi Chen
2026-08-28  8:47 ` Chaoyi Chen
2026-08-28  8:47 ` [PATCH v7 1/7] drm/bridge: aux-hpd-bridge: Add drm_dev_has_dp_hpd_bridge() Chaoyi Chen
2026-08-28  8:47   ` Chaoyi Chen
2026-08-28  8:47   ` Chaoyi Chen
2026-08-28  8:47 ` [PATCH v7 2/7] drm/bridge: Implement generic USB Type-C DP HPD bridge Chaoyi Chen
2026-08-28  8:47   ` Chaoyi Chen
2026-08-28  8:47   ` Chaoyi Chen
2026-08-28  9:04   ` sashiko-bot
2026-08-28  9:04     ` sashiko-bot
2026-08-28  8:47 ` [PATCH v7 3/7] drm/display: Add soft depend for aux-hpd-typec-dp-bridge module Chaoyi Chen
2026-08-28  8:47   ` Chaoyi Chen
2026-08-28  8:47   ` Chaoyi Chen
2026-08-28  8:56   ` sashiko-bot
2026-08-28  8:56     ` sashiko-bot
2026-08-28  8:47 ` [PATCH v7 4/7] drm/bridge: aux: Add drm_aux_bridge_register_from_node() Chaoyi Chen
2026-08-28  8:47   ` Chaoyi Chen
2026-08-28  8:47   ` Chaoyi Chen
2026-08-28  8:57   ` sashiko-bot
2026-08-28  8:57     ` sashiko-bot
2026-08-28  8:47 ` [PATCH v7 5/7] phy: rockchip: phy-rockchip-typec: Add DRM AUX bridge Chaoyi Chen
2026-08-28  8:47   ` Chaoyi Chen
2026-08-28  8:47   ` Chaoyi Chen
2026-08-28  9:01   ` sashiko-bot [this message]
2026-08-28  9:01     ` sashiko-bot
2026-08-28  8:47 ` [PATCH v7 6/7] drm/rockchip: cdn-dp: Support handle lane info without extcon Chaoyi Chen
2026-08-28  8:47   ` Chaoyi Chen
2026-08-28  8:47   ` Chaoyi Chen
2026-08-28  9:07   ` sashiko-bot
2026-08-28  9:07     ` sashiko-bot
2026-08-28  8:47 ` [PATCH v7 7/7] drm/rockchip: cdn-dp: Add multiple bridges to support PHY port selection Chaoyi Chen
2026-08-28  8:47   ` Chaoyi Chen
2026-08-28  8:47   ` Chaoyi Chen
2026-08-28  9:14   ` sashiko-bot
2026-08-28  9:14     ` sashiko-bot

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=20260828090123.5F35D1F00A3D@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kernel@airkyi.com \
    --cc=linux-phy@lists.infradead.org \
    --cc=neil.armstrong@linaro.org \
    --cc=olteanv@gmail.com \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=vkoul@kernel.org \
    /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.