All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Felix Gu" <ustc.gu@gmail.com>
Cc: linux-phy@lists.infradead.org, olteanv@gmail.com,
	vkoul@kernel.org, neil.armstrong@linaro.org
Subject: Re: [PATCH v2 2/2] phy: sunplus: fix ERR_PTR deref in update_disc_vol()
Date: Fri, 07 Aug 2026 13:38:26 +0000	[thread overview]
Message-ID: <20260807133827.570261F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260807-sunplus-v2-2-d5379c664dfc@gmail.com>

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

Pre-existing issues:
- [High] Missing validation of nvmem cell length can lead to an out-of-bounds read or ZERO_SIZE_PTR dereference.
- [High] Clock and reset control resources are leaked due to unbalanced operations in `sp_uphy_init()` error paths.
--

--- Patch [2]: [PATCH v2 2/2] phy: sunplus: fix ERR_PTR deref in update_disc_vol() ---
commit ec8ef9e1698074ff5a592bf46bc32ad0bdd396db
Author: Felix Gu <ustc.gu@gmail.com>

phy: sunplus: fix ERR_PTR deref in update_disc_vol()

nvmem_cell_get() returns ERR_PTR on failure. The code previously fell through
to nvmem_cell_read(), dereferencing the invalid pointer. This patch skips the
read and writes the default disconnect voltage when the lookup fails.

> diff --git a/drivers/phy/sunplus/phy-sunplus-usb2.c b/drivers/phy/sunplus/phy-sunplus-usb2.c
> index 842087bdfba53..eb834788ea2fc 100644
> --- a/drivers/phy/sunplus/phy-sunplus-usb2.c
> +++ b/drivers/phy/sunplus/phy-sunplus-usb2.c
> @@ -84,9 +84,10 @@ static int update_disc_vol(struct sp_usbphy *usbphy)
>  	u32 val, set = OTP_DISC_LEVEL_DEFAULT;
>  
>  	cell = nvmem_cell_get(usbphy->dev, disc_name);
> -	if (IS_ERR_OR_NULL(cell)) {
> +	if (IS_ERR(cell)) {
>  		if (PTR_ERR(cell) == -EPROBE_DEFER)
>  			return -EPROBE_DEFER;

[Severity: High]
This is a pre-existing issue, but does this return path leak the clock and
reset control references?

When update_disc_vol() returns -EPROBE_DEFER, the caller sp_uphy_init()
returns the error directly without performing cleanup:

sp_uphy_init() {
        ...
        ret = clk_prepare_enable(usbphy->phy_clk);
        if (ret)
                goto err_clk;

        ret = reset_control_deassert(usbphy->rstc);
        if (ret)
                goto err_reset;
        ...
        ret = update_disc_vol(usbphy);
        if (ret < 0)
                return ret;
        ...
}

This early return bypasses the err_reset and err_clk cleanup labels, leading
to unbounded incrementing of reference counts on subsequent retries if the
nvmem provider is not yet ready.

> +		goto skip_nvmem_read;
>  	}
>  
>  	otp_v = nvmem_cell_read(cell, &otp_l);

[Severity: High]
This isn't a bug introduced by this patch, but should the length of the
nvmem cell returned in otp_l be validated?

If nvmem_cell_read() returns a cell with a length of 0, the allocator returns
ZERO_SIZE_PTR which passes the !IS_ERR() check. Dereferencing this pointer
would trigger a page fault:

	if (!IS_ERR(otp_v)) {
		set = *(otp_v + 1);
		set = (set << (sizeof(char) * 8)) | *otp_v;

If the cell length is 1, *(otp_v + 1) would cause an out-of-bounds read.

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260807-sunplus-v2-0-d5379c664dfc@gmail.com?part=2

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

      reply	other threads:[~2026-08-07 13:38 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-07 13:16 [PATCH v2 0/2] phy: sunplus: fix two issues in update_disc_vol() Felix Gu
2026-08-07 13:16 ` Felix Gu
2026-08-07 13:16 ` [PATCH v2 1/2] phy: sunplus: fix memory leak " Felix Gu
2026-08-07 13:16   ` Felix Gu
2026-08-07 13:32   ` sashiko-bot
2026-08-07 13:17 ` [PATCH v2 2/2] phy: sunplus: fix ERR_PTR deref " Felix Gu
2026-08-07 13:17   ` Felix Gu
2026-08-07 13:38   ` sashiko-bot [this message]

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=20260807133827.570261F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-phy@lists.infradead.org \
    --cc=neil.armstrong@linaro.org \
    --cc=olteanv@gmail.com \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=ustc.gu@gmail.com \
    --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.