Re: [PATCH 1/3] x86: fix access_ok() and valid_user_address() using wrong USER_PTR_MAX in modules

[Linus Torvalds]

On Wed, 5 Nov 2025 at 04:07, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> Sadly, no. We've wanted to do that many times for various other
> reasons, and we really should, but because of historical semantics,
> some horrendous users still use "__get_user()" for addresses that
> might be user space or might be kernel space depending on use-case.
>
> Maybe we should bite the bullet and just break any remaining cases of
> that horrendous historical pattern. [...]

What I think is probably the right approach is to just take the normal
__get_user() calls - the ones that are obviously to user space, and
have an access_ok() - and just replace them with get_user().

That should all be very simple and straightforward for any half-way
normal code, and you won't see any downsides.

And in the unlikely case that you can measure any performance impact
because you had one single access_ok() and many __get_user() calls,
and *if* you really really care, that kind of code should be using
"user_read_access_begin()" and friends anyway, because unlike the
range checking, the *real* performance issue is almost certainly going
to be the cost of the CLAC/STAC instructions.

Put another way: __get_user() is simply always wrong these days.
Either it's wrong because it's a bad historical optimization that
isn't an optimization any more, or it's wrong because it's mis-using
the old semantics to play tricks with kernel-vs-user memory.

So we shouldn't try to "fix" __get_user(). We should aim to get rid of it.

             LInus