linux-kernel - Re: [PATCH v4] fs: hide names_cachep behind runtime access machinery

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-=wg8yBs7y+TVUFP=k=rjFa3eQFqqmXDDgnzN4buzSdToiA@mail.gmail.com>
Date: Fri, 31 Oct 2025 09:04:32 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Mateusz Guzik <mjguzik@...il.com>
Cc: Christian Brauner <brauner@...nel.org>, Thomas Gleixner <tglx@...utronix.de>, viro@...iv.linux.org.uk, 
	jack@...e.cz, linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org, 
	pfalcato@...e.de
Subject: Re: [PATCH v4] fs: hide names_cachep behind runtime access machinery

On Fri, 31 Oct 2025 at 08:13, Mateusz Guzik <mjguzik@...il.com> wrote:
>
> I slept on it and I think the pragmatic way forward is to split up
> runtime-const.h instead.

I don't think that would be wrong, but I do think the real bug was to
include runtime-const.h in any headers at all.

It should only be included by C code that is always built-in.

And it's all my fault and due to incompetence: this was introduced by
me in commit 86e6b1547b3d ("x86: fix user address masking
non-canonical speculation issue").

The original runtime const design was for core code optimization only,
and I just didn't think about the module case when I did that thing.

Sadly, this goes beyond just the trivial "access_ok()" - which can
trivially be fixed by just making it out-of-line. It ends up impacting
user address masking too.

It so happens that all our can_do_masked_user_access() optimizations
are in core code, so it's not an *actual* bug, just a potential one,
but it's one that Thomas' patches to do the nice scoped user accesses
will likely make much more common, just because his interface is so
much more convenient.

End result: I think your patch to just use

  #ifdef MODULE

in the header was the right one. Except instead of that

+#ifdef MODULE
+#define __USER_PTR_MAX USER_PTR_MAX
+#else

thing, I think the right thing to do is to just do

  #ifdef MODULE
   #include <asm-generic/runtime-const.h>
   #undef runtime_const_init
 #else
   #include <asm/runtime-const.h>
  #endif

in the x86 uaccess_64.h header file.

Let me think about this a bit more, but I feel really bad about having
missed this bug. I'm relieved to say that it looks largely harmless in
practice, but it really is me having royally messed up.

                  Linus