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

[Mateusz Guzik <mjguzik@gmail.com>]

On Tue, Nov 4, 2025 at 5:14 PM Borislav Petkov <bp@alien8.de> wrote:
>
> On Tue, Nov 04, 2025 at 11:25:44AM +0100, Borislav Petkov wrote:
> > On Tue, Nov 04, 2025 at 03:25:20PM +0900, Linus Torvalds wrote:
> > > Borislav - comments?
> >
> > LGTM at a quick glance but lemme take it for a spin around the hw jungle here
> > later and give it a more thorough look, once I've put out all the daily
> > fires...
>
> Did a deeper look, did randbuilds, boots fine on a couple of machines, so all
> good AFAIIC.
>
> I sincerely hope that helps.
>

Derailing the thread from the previous derailment with the following:

For unrelated reasons I disassembled kmem_cache_free and the following
goodies popped up:
sub    0x18e033f(%rip),%rax        # ffffffff82f944d0 <page_offset_base>
[..]
add    0x18e031d(%rip),%rax        # ffffffff82f944c0 <vmemmap_base>
[..]
mov    0x2189e19(%rip),%rax        # ffffffff8383e010 <__pi_phys_base>

These are definitely worthwhile to get rid of.

I'm just worried that given their low level nature they may happen to
be used before the runtime machinery is done patching and for now
can't be bothered to test that.

Worst case separate helpers could be added which are only legally used
after the patching and select cases like the above can get converted
to do it. Again not looking into it myself.

But perhaps someone would be interested? ;)

I'm responding to this e-mail since this would require some testing on
a bunch of uarchs most likely, especially with LA57.