From: sashiko-bot@kernel.org
To: "Chih Kai Hsu" <hsu.chih.kai@realtek.com>
Cc: linux-usb@vger.kernel.org
Subject: Re: [PATCH net-next v8 05/11] r8152: split r8156_init by generation and factor out wait_autoload_done
Date: Wed, 11 Nov 2026 03:25:14 +0000 [thread overview]
Message-ID: <sashiko-outbox-208186@kernel.org> (raw)
In-Reply-To: <20261110032416.16968-6-nic_swsd@realtek.com>
Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] r8152: uninitialized stack memory read via
read_poll_timeout() in wait_autoload_done()
--
commit 0223d579ae41de9da02eeed7c11b0b17d1632cc5
Author: Chih Kai Hsu <hsu.chih.kai@realtek.com>
r8152: split r8156_init by generation and factor out wait_autoload_done
This commit splits r8156_init() into r8156_init() and r8157_init() by chip
generation and factors the PLA_BOOT_CTRL polling loops into a shared
wait_autoload_done() helper using read_poll_timeout().
> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
> index 6f55aed4709e1..364a0573f6cd1 100644
> --- a/drivers/net/usb/r8152.c
> +++ b/drivers/net/usb/r8152.c
> @@ -4177,6 +4177,23 @@ static u16 r8153_phy_status(struct r8152 *tp, u16 desired)
> return data;
> }
>
> +static int wait_autoload_done(struct r8152 *tp)
> +{
> + u16 ocp_data;
> + int ret;
> +
> + ret = read_poll_timeout(ocp_read_word, ocp_data,
> + test_bit(RTL8152_INACCESSIBLE, &tp->flags) ||
> + (ocp_data & AUTOLOAD_DONE),
> + 20000, 10 * USEC_PER_SEC, false, tp,
> + MCU_TYPE_PLA, PLA_BOOT_CTRL);
> +
> + if (ret)
> + dev_err(&tp->intf->dev, "autoload done timeout\n");
> +
> + return test_bit(RTL8152_INACCESSIBLE, &tp->flags) ? -ENODEV : 0;
> +}
[Severity: Medium]
As reported by Jakub Kicinski on v7 [1], does read_poll_timeout() cause
ocp_read_word() to read and return uninitialized stack memory when
RTL8152_INACCESSIBLE is set?
read_poll_timeout() runs ocp_read_word() before evaluating the stop
condition test_bit(RTL8152_INACCESSIBLE, &tp->flags). When
RTL8152_INACCESSIBLE is set (for instance if a USB transfer fails during the
polling sleep, or in r8153b_ups_en() when the preceding ocp_read_word()
fails and returns 0xffff), generic_ocp_read() returns -ENODEV immediately
without initializing tmp, which ocp_read_word() then converts and returns by
value:
drivers/net/usb/r8152.c:ocp_read_word() {
...
generic_ocp_read(tp, index, sizeof(tmp), &tmp, type | byen);
data = __le32_to_cpu(tmp);
data >>= (shift * 8);
data &= 0xffff;
return (u16)data;
}
Returning an uninitialized value triggers a KMSAN uninit-value report, and
if generic_ocp_read() instead fails with -ENOMEM in get_registers() without
setting RTL8152_INACCESSIBLE, wait_autoload_done() also branches on the
uninitialized ocp_data.
[1] https://lore.kernel.org/r/20261021005210.1254886-1-kuba@kernel.org
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261110032416.16968-1-nic_swsd@realtek.com?part=5
next prev parent reply other threads:[~2026-11-11 3:25 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-10 3:24 [PATCH net-next v8 00/11] r8152: refactor and extend RTL8157/8159 support Chih Kai Hsu
2026-11-10 3:24 ` [PATCH net-next v8 01/11] r8152: fix RTL8156/RTL8156B/RTL8157/RTL8159 up and down settings Chih Kai Hsu
2026-11-11 3:25 ` sashiko-bot
2026-11-10 3:24 ` [PATCH net-next v8 02/11] r8152: add rtl8157_unload() for RTL8157 and RTL8159 Chih Kai Hsu
2026-11-11 3:25 ` sashiko-bot
2026-11-10 3:24 ` [PATCH net-next v8 03/11] r8152: add rtl8157_change_mtu() " Chih Kai Hsu
2026-11-11 3:25 ` sashiko-bot
2026-11-10 3:24 ` [PATCH net-next v8 04/11] r8152: fix flow control for RTL8156/RTL8156B/RTL8157/RTL8159 Chih Kai Hsu
2026-11-11 3:25 ` sashiko-bot
2026-11-10 3:24 ` [PATCH net-next v8 05/11] r8152: split r8156_init by generation and factor out wait_autoload_done Chih Kai Hsu
2026-11-11 3:25 ` sashiko-bot [this message]
2026-11-10 3:24 ` [PATCH net-next v8 06/11] r8152: add new init writes for RTL8156/8156B/8157/8159 Chih Kai Hsu
2026-11-11 3:25 ` sashiko-bot
2026-11-10 3:24 ` [PATCH net-next v8 07/11] r8152: split RTL_VER_17 into QFN68 and QFN100 package variants Chih Kai Hsu
2026-11-11 3:25 ` sashiko-bot
2026-11-10 3:24 ` [PATCH net-next v8 08/11] r8152: split rtl8156_enable/up/down into per-generation functions Chih Kai Hsu
2026-11-11 3:25 ` sashiko-bot
2026-11-10 3:24 ` [PATCH net-next v8 09/11] r8152: split r8157_hw_phy_cfg into RTL8157 and RTL8159 variants Chih Kai Hsu
2026-11-11 3:25 ` sashiko-bot
2026-11-10 3:24 ` [PATCH net-next v8 10/11] r8152: add TGPHY register access for RTL8157 and RTL8159 Chih Kai Hsu
2026-11-11 3:25 ` sashiko-bot
2026-11-10 3:24 ` [PATCH net-next v8 11/11] r8152: enable UPS for RTL8157 and RTL8159 QFN68 Chih Kai Hsu
2026-11-11 3:25 ` sashiko-bot
2026-11-10 5:04 ` [PATCH net-next v8 00/11] r8152: refactor and extend RTL8157/8159 support netdev-bot+sinfo
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=sashiko-outbox-208186@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=hsu.chih.kai@realtek.com \
--cc=linux-usb@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox