All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Xu Yang" <xu.yang_2@oss.nxp.com>
Cc: olteanv@gmail.com, linux-phy@lists.infradead.org,
	imx@lists.linux.dev, vkoul@kernel.org, Frank.Li@kernel.org,
	neil.armstrong@linaro.org
Subject: Re: [PATCH v6 1/6] phy: fsl-imx8mq-usb: fix typec switch leak on probe error path
Date: Wed, 15 Jul 2026 11:46:25 +0000	[thread overview]
Message-ID: <20260715114626.651A81F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260715-imx8mp-usb-phy-improvement-v6-1-00d95e270e4c@nxp.com>

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

Pre-existing issues:
- [High] The Type-C switch callback `tca_blk_typec_switch_set` can be invoked after the PHY driver is unbound, leading to a Use-After-Free of the driver context.
--

--- Patch [1]: [PATCH v6 1/6] phy: fsl-imx8mq-usb: fix typec switch leak on probe error path ---
commit 5e0093cfdd6e9dd648ed3549eb93bacb54164be2
Author: Felix Gu <ustc.gu@gmail.com>

phy: fsl-imx8mq-usb: fix typec switch leak on probe error path

This commit fixes a typec switch resource leak when probe fails after
imx95_usb_phy_get_tca() succeeds. It transitions the cleanup of the switch
to use devm_add_action_or_reset() so that it is properly freed on both
probe failure and driver removal.

> diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> index b05d80e849a14..9a33c06d6fc39 100644
> --- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> +++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> @@ -173,9 +173,9 @@ static struct typec_switch_dev *tca_blk_get_typec_switch(struct platform_device
>  	return sw;
>  }
>  
> -static void tca_blk_put_typec_switch(struct typec_switch_dev *sw)
> +static void tca_blk_put_typec_switch(void *data)
>  {
> -	typec_switch_unregister(sw);
> +	typec_switch_unregister(data);

[Severity: High]
This is a pre-existing issue, but does typec_switch_unregister() guarantee
that no consumers will invoke the .set callback afterwards?

If a consumer acquires the switch using fwnode_typec_switch_get() and holds
a reference, it appears typec_switch_unregister() removes the device from
sysfs but doesn't revoke the consumer's ability to call sw_dev->set().

Because imx_phy and tca are allocated with devm_kzalloc() during probe, they
are automatically freed when the provider unbinds. Could this lead to a
use-after-free if the consumer asynchronously calls typec_switch_set():

tca_blk_typec_switch_set()
    struct imx8mq_usb_phy *imx_phy = typec_switch_get_drvdata(sw);
    struct tca_blk *tca = imx_phy->tca;

where imx_phy has already been freed by the devm teardown?

>  }
>  
>  static void tca_blk_orientation_set(struct tca_blk *tca,

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260715-imx8mp-usb-phy-improvement-v6-0-00d95e270e4c@nxp.com?part=1

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

WARNING: multiple messages have this Message-ID (diff)
From: sashiko-bot@kernel.org
To: "Xu Yang" <xu.yang_2@oss.nxp.com>
Cc: olteanv@gmail.com, linux-phy@lists.infradead.org,
	imx@lists.linux.dev, vkoul@kernel.org, Frank.Li@kernel.org,
	neil.armstrong@linaro.org
Subject: Re: [PATCH v6 1/6] phy: fsl-imx8mq-usb: fix typec switch leak on probe error path
Date: Wed, 15 Jul 2026 11:46:25 +0000	[thread overview]
Message-ID: <20260715114626.651A81F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260715-imx8mp-usb-phy-improvement-v6-1-00d95e270e4c@nxp.com>

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

Pre-existing issues:
- [High] The Type-C switch callback `tca_blk_typec_switch_set` can be invoked after the PHY driver is unbound, leading to a Use-After-Free of the driver context.
--

--- Patch [1]: [PATCH v6 1/6] phy: fsl-imx8mq-usb: fix typec switch leak on probe error path ---
commit 5e0093cfdd6e9dd648ed3549eb93bacb54164be2
Author: Felix Gu <ustc.gu@gmail.com>

phy: fsl-imx8mq-usb: fix typec switch leak on probe error path

This commit fixes a typec switch resource leak when probe fails after
imx95_usb_phy_get_tca() succeeds. It transitions the cleanup of the switch
to use devm_add_action_or_reset() so that it is properly freed on both
probe failure and driver removal.

> diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> index b05d80e849a14..9a33c06d6fc39 100644
> --- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> +++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> @@ -173,9 +173,9 @@ static struct typec_switch_dev *tca_blk_get_typec_switch(struct platform_device
>  	return sw;
>  }
>  
> -static void tca_blk_put_typec_switch(struct typec_switch_dev *sw)
> +static void tca_blk_put_typec_switch(void *data)
>  {
> -	typec_switch_unregister(sw);
> +	typec_switch_unregister(data);

[Severity: High]
This is a pre-existing issue, but does typec_switch_unregister() guarantee
that no consumers will invoke the .set callback afterwards?

If a consumer acquires the switch using fwnode_typec_switch_get() and holds
a reference, it appears typec_switch_unregister() removes the device from
sysfs but doesn't revoke the consumer's ability to call sw_dev->set().

Because imx_phy and tca are allocated with devm_kzalloc() during probe, they
are automatically freed when the provider unbinds. Could this lead to a
use-after-free if the consumer asynchronously calls typec_switch_set():

tca_blk_typec_switch_set()
    struct imx8mq_usb_phy *imx_phy = typec_switch_get_drvdata(sw);
    struct tca_blk *tca = imx_phy->tca;

where imx_phy has already been freed by the devm teardown?

>  }
>  
>  static void tca_blk_orientation_set(struct tca_blk *tca,

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260715-imx8mp-usb-phy-improvement-v6-0-00d95e270e4c@nxp.com?part=1

  reply	other threads:[~2026-07-15 11:46 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-15 11:33 [PATCH v6 0/6] phy: fsl-imx8mq-usb: few improvements Xu Yang
2026-07-15 11:33 ` Xu Yang
2026-07-15 11:33 ` [PATCH v6 1/6] phy: fsl-imx8mq-usb: fix typec switch leak on probe error path Xu Yang
2026-07-15 11:33   ` Xu Yang
2026-07-15 11:46   ` sashiko-bot [this message]
2026-07-15 11:46     ` sashiko-bot
2026-07-15 11:33 ` [PATCH v6 2/6] phy: fsl-imx8mq-usb: set usb phy to be wakeup capable Xu Yang
2026-07-15 11:33   ` Xu Yang
2026-07-15 11:33 ` [PATCH v6 3/6] phy: fsl-imx8mq-usb: add runtime PM support Xu Yang
2026-07-15 11:33   ` Xu Yang
2026-07-15 11:52   ` sashiko-bot
2026-07-15 11:52     ` sashiko-bot
2026-07-15 15:28   ` Frank Li
2026-07-15 15:28     ` Frank Li
2026-07-15 11:33 ` [PATCH v6 4/6] phy: fsl-imx8mq-usb: add control register regmap Xu Yang
2026-07-15 11:33   ` Xu Yang
2026-07-15 11:34 ` [PATCH v6 5/6] phy: fsl-imx8mq-usb: introduce per-variant driver data structure Xu Yang
2026-07-15 11:34   ` Xu Yang
2026-07-15 15:29   ` Frank Li
2026-07-15 15:29     ` Frank Li
2026-07-15 11:34 ` [PATCH v6 6/6] phy: fsl-imx8mq-usb: keep PHY power domain runtime always-on for i.MX8MP Xu Yang
2026-07-15 11:34   ` Xu Yang
2026-07-15 11:44   ` sashiko-bot
2026-07-15 11:44     ` sashiko-bot
2026-07-15 15:32   ` Frank Li
2026-07-15 15:32     ` Frank Li

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=20260715114626.651A81F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=Frank.Li@kernel.org \
    --cc=imx@lists.linux.dev \
    --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 \
    --cc=xu.yang_2@oss.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.