All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Felix Gu" <ustc.gu@gmail.com>
Cc: olteanv@gmail.com, neil.armstrong@linaro.org,
	linux-phy@lists.infradead.org, vkoul@kernel.org
Subject: Re: [PATCH] phy: sunplus: fix crash when the disc_vol nvmem cell is missing
Date: Tue, 04 Aug 2026 14:29:07 +0000	[thread overview]
Message-ID: <20260804142908.CCE8E1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260804-sunplus-v1-1-79f52226cb50@gmail.com>

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

Pre-existing issues:
- [High] Missing length check on the dynamically sized buffer returned by nvmem_cell_read() leads to a heap out-of-bounds read and potential information leak to MMIO.
- [High] Clock and reset resource leak in sp_uphy_init() error path when update_disc_vol() fails.
--

--- Patch [1]: [PATCH] phy: sunplus: fix crash when the disc_vol nvmem cell is missing ---
commit 3ff3eec8ebe3bd1dab2325248c9d68c39dbf60d4
Author: Felix Gu <ustc.gu@gmail.com>

phy: sunplus: fix crash when the disc_vol nvmem cell is missing

nvmem_cell_get() can fail with errors other than -EPROBE_DEFER, but
update_disc_vol() only handled -EPROBE_DEFER and then called
nvmem_cell_read() with the error pointer, crashing the kernel.

Fall back to the default disconnect voltage on a failed cell lookup,
and free the buffer returned by nvmem_cell_read().

> diff --git a/drivers/phy/sunplus/phy-sunplus-usb2.c b/drivers/phy/sunplus/phy-sunplus-usb2.c
> index 637a5fbae6d9a..94146118e9c2e 100644
> --- a/drivers/phy/sunplus/phy-sunplus-usb2.c
> +++ b/drivers/phy/sunplus/phy-sunplus-usb2.c
> @@ -81,12 +81,13 @@ static int update_disc_vol(struct sp_usbphy *usbphy)
>  	char *disc_name = "disc_vol";
>  	ssize_t otp_l = 0;
>  	char *otp_v;
> -	u32 val, set;
> +	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 isn't a bug introduced by this patch, but if update_disc_vol()
returns -EPROBE_DEFER here, do we leak the clock and reset resources in
sp_uphy_init()?

In 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;

It looks like this returns directly instead of routing to the err_reset and
err_clk cleanup labels.

> +		goto out;
>  	}
>  
>  	otp_v = nvmem_cell_read(cell, &otp_l);
> @@ -96,11 +97,12 @@ static int update_disc_vol(struct sp_usbphy *usbphy)
>  		set = *(otp_v + 1);
>  		set = (set << (sizeof(char) * 8)) | *otp_v;
>  		set = (set >> usbphy->disc_vol_addr_off) & J_DISC;

[Severity: High]
This is a pre-existing issue, but is it safe to unconditionally access two
bytes from the nvmem buffer without checking the returned length (otp_l)?

The nvmem_cell_read() function dynamically allocates a buffer sized exactly
to the cell's byte count. If the NVMEM cell is defined as 1 byte in the
device tree, wouldn't *(otp_v + 1) result in a slab out-of-bounds read?

> +		if (set == 0)
> +			set = OTP_DISC_LEVEL_DEFAULT;
> +		kfree(otp_v);
>  	}
>  
> -	if (IS_ERR(otp_v) || set == 0)
> -		set = OTP_DISC_LEVEL_DEFAULT;
> -
> +out:
>  	val = readl(usbphy->phy_regs + CONFIG7);
>  	val = (val & ~J_DISC) | set;
>  	writel(val, usbphy->phy_regs + CONFIG7);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260804-sunplus-v1-1-79f52226cb50@gmail.com?part=1

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

  reply	other threads:[~2026-08-04 14:29 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-04 13:58 [PATCH] phy: sunplus: fix crash when the disc_vol nvmem cell is missing Felix Gu
2026-08-04 13:58 ` Felix Gu
2026-08-04 14:29 ` sashiko-bot [this message]
2026-08-06 10:22 ` Vinod Koul
2026-08-06 10:22   ` Vinod Koul

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=20260804142908.CCE8E1F000E9@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.