dev->chipid is used in lan78xx_init_mac_address before it's initialized:

lan78xx_reset() {
    lan78xx_init_mac_address()
        lan78xx_read_eeprom()
            lan78xx_read_raw_eeprom() <- dev->chipid is used here

    dev->chipid = ... <- dev->chipid is initialized correctly here
}

Reorder initialization so that dev->chipid is set before calling
lan78xx_init_mac_address().

Signed-off-by: I Viswanath <viswanathiyyappan@gmail.com>
---
 
KMSAN didn't detect this issue because dev->chipid is zero
initialized from alloc_etherdev

 drivers/net/usb/lan78xx.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index 1ff25f57329a..f3831ecaaec1 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -3238,10 +3238,6 @@ static int lan78xx_reset(struct lan78xx_net *dev)
 		}
 	} while (buf & HW_CFG_LRST_);
 
-	ret = lan78xx_init_mac_address(dev);
-	if (ret < 0)
-		return ret;
-
 	/* save DEVID for later usage */
 	ret = lan78xx_read_reg(dev, ID_REV, &buf);
 	if (ret < 0)
@@ -3250,6 +3246,10 @@ static int lan78xx_reset(struct lan78xx_net *dev)
 	dev->chipid = (buf & ID_REV_CHIP_ID_MASK_) >> 16;
 	dev->chiprev = buf & ID_REV_CHIP_REV_MASK_;
 
+	ret = lan78xx_init_mac_address(dev);
+	if (ret < 0)
+		return ret;
+
 	/* Respond to the IN token with a NAK */
 	ret = lan78xx_read_reg(dev, USB_CFG0, &buf);
 	if (ret < 0)
-- 
2.47.3

On 10/1/25 09:14, I Viswanath wrote:
> dev->chipid is used in lan78xx_init_mac_address before it's initialized:
> 
> lan78xx_reset() {
>     lan78xx_init_mac_address()
>         lan78xx_read_eeprom()
>             lan78xx_read_raw_eeprom() <- dev->chipid is used here
> 
>     dev->chipid = ... <- dev->chipid is initialized correctly here
> }

Please describe the testing you performed.

On Tue, 7 Oct 2025 at 06:52, David Hunter <david.hunter.linux@gmail.com> wrote:
>
> Please describe the testing you performed.

I used the reproducer provided at
https://syzkaller.appspot.com/bug?extid=62ec8226f01cb4ca19d9 and QEMU
to verify my patch.

I applied the fix patch for the bug before my testing.

For testing, I set a hardware breakpoint at lan78xx_init_mac_address,
triggered the reproducer, and inspected the value of dev->chipid at
that point.

Without my patch, dev->chipid was always 0. With my patch, it matched
the upper 16 bits of the value read from the ID_REV register

Thanks
I Viswanath

On Wed,  1 Oct 2025 18:44:09 +0530 I Viswanath wrote:
> dev->chipid is used in lan78xx_init_mac_address before it's initialized:
> 
> lan78xx_reset() {
>     lan78xx_init_mac_address()
>         lan78xx_read_eeprom()
>             lan78xx_read_raw_eeprom() <- dev->chipid is used here
> 
>     dev->chipid = ... <- dev->chipid is initialized correctly here
> }
> 
> Reorder initialization so that dev->chipid is set before calling
> lan78xx_init_mac_address().

We need a Fixes tag
-- 
pw-bot: cr

On Mon, 6 Oct 2025 at 23:42, Jakub Kicinski <kuba@kernel.org> wrote:

> We need a Fixes tag

a0db7d10b76e ("lan78xx: Add to handle mux control per chip id") seems
to be most suitable commit: It added dev->devid comparisons to
lan78xx_read_raw_eeprom but did not move the dev->devid read before
the call (devid is the precursor to chipid and chiprev)

I feel like the patch title sounds a bit awkward so should I change it to

"Initialize dev->chipid before use in lan78xx_read_raw_eeprom"

since that sounds more standard

in v2

Thanks
I Viswanath