netdev - Re: [GIT PULL] wireless-2025-07-10

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: <934e5e1e253ee3025f617cc38ce6fc15e0619d6c.camel@sipsolutions.net>
Date: Fri, 11 Jul 2025 08:41:28 +0200
From: Johannes Berg <johannes@...solutions.net>
To: Jakub Kicinski <kuba@...nel.org>
Cc: netdev@...r.kernel.org, linux-wireless@...r.kernel.org
Subject: Re: [GIT PULL] wireless-2025-07-10

On Thu, 2025-07-10 at 17:23 -0700, Jakub Kicinski wrote:
> On Thu, 10 Jul 2025 14:21:06 +0200 Johannes Berg wrote:
> > So I have more fixes than I'd like at this point, but a few
> > were under discussion for a while, mt76 fixes were just not
> > forthcoming until now, and all of them really don't seem
> > wrong to put into the tree at this point...
> > 
> > Please pull and let us know if there's any problem.
> 
> Some good news and some bad news. Bad news is that this missed today's
> PR. Good news is that we shipped a bug to Linus which is likely to
> break nl80211 users:
> https://lore.kernel.org/all/20250711001121.3649033-1-kuba@kernel.org/
> so I'm gonna send a second PR tomorrow, with the netlink fix and I'll
> include your fixes in it. I suppose you may want to wait with the fast
> forward until then. 
> Now that I typed this I guess it may be two pieces of bad news..

No worries, and thanks for the heads-up, I can wait. I actually really
hope this was the last pull request for the current -rc cycle anyway,
but of course now that I said it someone's going to come out of the
woodwork with a fix ;)

Re the size problem, nl80211 can indeed create and fill really big SKBs
if userspace gives a big buffer, which it often does. Looking at it now,
I'm not sure why we set the rcvbuf to 8KiB in iw? That seems ... odd. It
looks like I originally did that to _increase_ it, but that seems
completely off, and my first fix didn't even do anything. Then we fixed
the call but ...

Looks like the problem is entirely self-made there, but I guess we still
have to live with stupid userspace, sorry about that. I can take a
closer look at it all and try to fix things there, if you think it's
worth it?

johannes