linux-kernel - Re: [PATCH v2 02/12] wifi: mwifiex: fix MAC address handling

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

Message-ID: <ZwD-9nV3o2fOpEYb@gaggiata.pivistrello.it>
Date: Sat, 5 Oct 2024 10:55:18 +0200
From: Francesco Dolcini <francesco@...cini.it>
To: Brian Norris <briannorris@...omium.org>,
	Sascha Hauer <s.hauer@...gutronix.de>
Cc: Francesco Dolcini <francesco@...cini.it>, Kalle Valo <kvalo@...nel.org>,
	linux-wireless@...r.kernel.org, linux-kernel@...r.kernel.org,
	David Lin <yu-hao.lin@....com>, kernel@...gutronix.de,
	stable@...r.kernel.org
Subject: Re: [PATCH v2 02/12] wifi: mwifiex: fix MAC address handling

On Fri, Oct 04, 2024 at 04:15:32PM -0700, Brian Norris wrote:
> On Wed, Sep 18, 2024 at 01:10:27PM +0200, Sascha Hauer wrote:
> > Furthermore the driver doesn't use the permanent address to add the
> > bss_num to, but instead the current MAC address increases each time
> > we do a change_virtual_intf.
> > 
> > Fix this by initializing the MAC address once from the permanent MAC
> > address during creation of the virtual interface and never touch it
> > again. This also means that userspace can set a different MAC address
> > which then stays like this forever and is not unexpectedly changed
> > by the driver.
> > 
> > It is not clear how many (if any) MAC addresses after the permanent MAC
> > address are reserved for a device, so set the locally admistered
> > bit for all MAC addresses derived from the permanent address.
> 
> I think I'm generally supportive of the direction this changes things,
> but I'm a bit hesitant about two things:

FTR, I am hesitant for similar reasons. In addition there is my comment
from the previous version on a specific use case potentially broken.

> And I see that you rightly don't know how many addresses are actually
> reserved, but I have an educated guess that it's not just 1. For one,
> this driver used to default-create 3 interfaces:

The MAC addresses on the module are not allocated by the Wi-Fi chip vendor (NXP,
and before Marvell), but by whom is integrating the chip. I can try to ask
a couple of vendors what they are doing on this regard, and if this is somehow
suggested by NXP or they are just doing whatever they believe is right. Just to
add a couple of more data points to this discussion.

Francesco