netdev - Re: [PATCH net] net: usb: usbnet: fix name regression

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2024120259-diaphragm-unspoken-5fe0@gregkh>
Date: Mon, 2 Dec 2024 07:29:52 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Dominique MARTINET <dominique.martinet@...ark-techno.com>
Cc: Oliver Neukum <oneukum@...e.com>, edumazet@...gle.com, kuba@...nel.org,
	pabeni@...hat.com, netdev@...r.kernel.org,
	Greg Thelen <gthelen@...gle.com>,
	John Sperbeck <jsperbeck@...gle.com>, stable@...r.kernel.org
Subject: Re: [PATCH net] net: usb: usbnet: fix name regression

On Mon, Dec 02, 2024 at 12:50:15PM +0900, Dominique MARTINET wrote:
> Hi,
> 
> Oliver Neukum wrote on Thu, Oct 17, 2024 at 09:18:37AM +0200:
> > The fix for MAC addresses broke detection of the naming convention
> > because it gave network devices no random MAC before bind()
> > was called. This means that the check for the local assignment bit
> > was always negative as the address was zeroed from allocation,
> > instead of from overwriting the MAC with a unique hardware address.
> 
> So we hit the exact inverse problem with this patch: our device ships an
> LTE modem which exposes a cdc-ethernet interface that had always been
> named usb0, and with this patch it started being named eth1, breaking
> too many hardcoded things expecting the name to be usb0 and making our
> devices unable to connect to the internet after updating the kernel.
> 
> 
> Long term we'll probably add an udev rule or something to make the name
> explicit in userspace and not risk this happening again, but perhaps
> there's a better way to keep the old behavior?
> 
> (In particular this hit all stable kernels last month so I'm sure we
> won't be the only ones getting annoyed with this... Perhaps reverting
> both patches for stable branches might make sense if no better way
> forward is found -- I've added stable@ in cc for heads up/opinions)

Device names have NEVER been stable.  They move around and can change on
every boot, let alone almost always changing between kernel versions.
That's why we created udev, to solve this issue.

But how is changing the MAC address changing the device naming here?
How are they linked to suddenly causing the names to switch around?

thanks,

greg k-h