linux-kernel - Re: [GIT PULL] locking/urgent for v6.17-rc1

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: <CAHk-=wi+X2A6K839AxrRvaCDCakya-2B68NTkYP5YGfi-h5EuQ@mail.gmail.com>
Date: Thu, 21 Aug 2025 14:19:31 -0400
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Borislav Petkov <bp@...en8.de>, Thomas Gleixner <tglx@...utronix.de>, 
	Sebastian Andrzej Siewior <bigeasy@...utronix.de>, Peter Zijlstra <peterz@...radead.org>
Cc: x86-ml <x86@...nel.org>, lkml <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] locking/urgent for v6.17-rc1

On Sat, 9 Aug 2025 at 14:02, Borislav Petkov <bp@...en8.de> wrote:
>
> please pull a locking/urgent fix for v6.17-rc1.

Ok, so this clearly wasn't a fix.

> Thomas Gleixner (1):
>       futex: Move futex cleanup to __mmdrop()

So this causes problems, because __mmdrop is not done in thread
context, and the kvfree() calls then cause issues:

  https://lore.kernel.org/all/20250821102721.6deae493@kernel.org/
  https://lore.kernel.org/all/20250818131902.5039-1-hdanton@sina.com/

Hilf Danton sent out a patch, but honestly, that patch looks like pure
bandaid, and will make the exit path horribly much slower by moving
things into workqueues. It might not be visible in profiles exactly
*because* it's then hidden in workqueues, but it's not great.

I think it's a mistake to allow vmalloc'ing those hashes in the first
place, and I suggest the local hash be size-limited to the point where
it's just a kmalloc() and thus works in all contexts.

Or maybe the mistake was the mm-private hashing in the first place.
Maybe that hash shouldn't be allocated at mm_alloc() ->
futex_mm_init() at all. Only initialized by the futex code when
needed, and then dropped in exit_mmap().

So the problems seem deeper than just "free'd in the wrong context".

           Linus