linux-kernel - SMSC911X MAC Read Corruption

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <aAAN49MP-JeU4g1A@colin-ia-desktop>
Date: Wed, 16 Apr 2025 15:06:59 -0500
From: Colin Foster <colin.foster@...advantage.com>
To: linux-kernel@...r.kernel.org
Cc: "netdev@...r.kernel.org Paolo Abeni" <pabeni@...hat.com>,
	Jakub Kicinski <kuba@...nel.org>,
	Eric Dumazet <edumazet@...gle.com>,
	"David S. Miller" <davem@...emloft.net>,
	Andrew Lunn <andrew+netdev@...n.ch>,
	Steve Glendinning <steve.glendinning@...well.net>
Subject: SMSC911X MAC Read Corruption

Hello,

I have a fairly old system running an SMSC9221 chip. We've seen that the
last two octets of our MACs are all zero. (I'm currently testing on
6.12.23)

I've found that the first smsc911x_mac_read(pData, *) call seems to
return zero, and subsequent reads succeed.

---------8<------------
static void smsc911x_read_mac_address(struct net_device *dev)
{
        struct smsc911x_data *pdata = netdev_priv(dev);
        u32 mac_high16 = smsc911x_mac_read(pdata, ADDRH);
        u32 mac_low32 = smsc911x_mac_read(pdata, ADDRL);
        u8 addr[ETH_ALEN];

        addr[0] = (u8)(mac_low32);
        addr[1] = (u8)(mac_low32 >> 8);
        addr[2] = (u8)(mac_low32 >> 16);
        addr[3] = (u8)(mac_low32 >> 24);
        addr[4] = (u8)(mac_high16);
        addr[5] = (u8)(mac_high16 >> 8);
        eth_hw_addr_set(dev, addr);
}
---------8<------------

Simply reading the ADDRH twice causes the issue to go away.

I was attempting to upstream the DTS a while back, but hit a wall
troubleshooting gremlins I still haven't uncovered:

https://lkml.org/lkml/2023/2/8/1289

I figure this is either:

  1. An issue for everyone, but nobody notices (because the
     hardware combination is rare, or MAC collisions simply
     are missed)
  2. An issue for just me due to a DTS error (which is usually
     the case)

So maybe this is a question around (1). If this is an issue for
everyone, I'm happy to send a patch to read mac_high16 twice if the
first read is 0x0000. Or if there are any other ideas, I'm willing
to try whatever might be suggested.

Thanks,

Colin Foster