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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHk-=wifyJz+WCZxHo6FLht380Y7uQAxX-=RqNh7u4978zhggg@mail.gmail.com>
Date: Thu, 30 Oct 2025 11:25:47 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Mateusz Guzik <mjguzik@...il.com>, Thomas Gleixner <tglx@...utronix.de>
Cc: brauner@...nel.org, 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 Thu, 30 Oct 2025 at 11:07, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> ENTIRELY UNTESTED PATCH attached - may not compile at all, but
> something like this *might* work to show when a module uses the
> runtime_const infrastructure.

Hmm. I tested it, and it seems to work. And by "work", I mean "show
real existing problems":

  ERROR: modpost: "no_runtime_const" [arch/x86/kvm/kvm.ko] undefined!
  ERROR: modpost: "no_runtime_const" [arch/x86/kvm/kvm-amd.ko] undefined!
  ERROR: modpost: "no_runtime_const" [fs/erofs/erofs.ko] undefined!
  ERROR: modpost: "no_runtime_const" [lib/tests/usercopy_kunit.ko] undefined!
  ERROR: modpost: "no_runtime_const" [lib/test_lockup.ko] undefined!
  ERROR: modpost: "no_runtime_const" [drivers/acpi/acpi_dbg.ko] undefined!
  ERROR: modpost: "no_runtime_const" [drivers/xen/xen-privcmd.ko] undefined!
  ERROR: modpost: "no_runtime_const"
[drivers/iommu/iommufd/iommufd.ko] undefined!
  ERROR: modpost: "no_runtime_const" [drivers/gpu/drm/drm.ko] undefined!
  ERROR: modpost: "no_runtime_const"
[drivers/gpu/drm/radeon/radeon.ko] undefined!
  WARNING: modpost: suppressed 29 unresolved symbol warnings because
there were too many)

and yeah, I think it comes from access_ok() use.

It turns out that all of this "works", but entirely by mistake, and
not really properly.

I picked the default value for the runtime_const pointer of
0x0123456789abcdef because it's easy to see in disassembly, and
because it causes a nice oops if not fixed up because it's a
non-canonical address on normal x86-64.

And *because* it's in that non-canonical range, it's actually "good
enough" for access_ok() in practice. But it sure as hell ain't right.

I think that for x86-64 and for the short term, the right thing to do
is to make access_ok() be out-of-line. Nobody should use it any more
anyway, it's a legacy operation for back when doing access_ok() +
__get_user() was a big and valid optimization.

So I think the other thing that kind of saved us - but probably also
meant that the bug wasn't as obvious as it should have been - was
exactly the fact that it affects that operation that really nobody
should use anyway.

               Linus