linux-kernel - Re: [PATCH 1/3] x86: fix access_ok() and valid_user_address() using wrong USER_PTR

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: <CAGudoHF7O-q4AENo-jdZymr+U8AGfQBcz7hjbi-kTg=MSOECXg@mail.gmail.com>
Date: Thu, 6 Nov 2025 15:49:25 +0100
From: Mateusz Guzik <mjguzik@...il.com>
To: Borislav Petkov <bp@...en8.de>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>, 
	"the arch/x86 maintainers" <x86@...nel.org>, brauner@...nel.org, viro@...iv.linux.org.uk, jack@...e.cz, 
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org, 
	tglx@...utronix.de, pfalcato@...e.de
Subject: Re: [PATCH 1/3] x86: fix access_ok() and valid_user_address() using
 wrong USER_PTR_MAX in modules

On Thu, Nov 6, 2025 at 2:37 PM Borislav Petkov <bp@...en8.de> wrote:
>
> On Thu, Nov 06, 2025 at 02:19:06PM +0100, Mateusz Guzik wrote:
> > Then, as I pointed out, you should be protesting the patching of
> > USER_PTR_MAX as it came with no benchmarks
>
> That came in as a security fix. I'd say correctness before performance. And if
> anyone finds a better and faster fix and can prove it, I'm all ears.
>

Perhaps I failed to state my point clearly.

The position you are describing above does not line up with your
behavior concerning the use of runtime-const machinery for
USER_PTR_MAX.

It is purely an optimization and it has nothing to do with fixing the
problem the commit introducing it was aiming to solve. You accept it
without a benchmark. Later when a bug was identified you did some
testing to make sure it works. I think it that made sense. However,
per what you are describing above I would expect you would be
questioning whether this is warranted in the first place.

kmem is probably used about as often as user access (if not more so).
To my reading you rejected the idea of patching up some of its memory
accesses without a benchmark from the get go, which is quite a
different stance and I find myself confused about the discrepancy.

I have not tried to write patches to optimize these. There is a
threshold of complexity/ugliness where I would drop the idea myself.
But in a hypothetical case where they turn out fine, I don't
understand what's up with the insistence on benchmarks for this
particular thing, especially in light of your position on
USER_PTR_MAX. Per what I described previously, this would be hard to
arrange anyway even if someone genuinely tried.