BUG: KASAN: vmalloc-out-of-bounds in copy_to_kernel_nofault+0xd8/0x1c8 (v6.13-rc6, PowerMac G4)

[Linus Torvalds]

On Tue, 21 Jan 2025 at 13:00, Erhard Furtner <erhard_f at mailbox.org> wrote:
>
>
> Meanwhile I bisected the bug. Offending commit is:
>
>  # git bisect good
> 32913f348229c9f72dda45fc2c08c6d9dfcd3d6d is the first bad commit
> commit 32913f348229c9f72dda45fc2c08c6d9dfcd3d6d
> Author: Linus Torvalds <torvalds at linux-foundation.org>
> Date:   Mon Dec 9 10:00:25 2024 -0800
>
>     futex: fix user access on powerpc

Heh. As Christophe said - very funky.  All that commit does is fix the
user_access_end() to be a user_read_access_end() so that it pairs
correctly with the user_read_access_begin().

On other architectures is a complete no-op, but even on powerpc that
literally just changes a

        prevent_user_access(KUAP_READ_WRITE);

into a

        prevent_user_access(KUAP_READ);

unless I'm missing something. So it's really not a big change even on powerpc.

If I'm parsing your config file correctly, this is the 32-bit "book3"
case, so we're talking about the prevent_user_access() in

  arch/powerpc/include/asm/book3s/32/kup.h

and those things end up being no-ops for non-write cases:

        if (!(dir & KUAP_WRITE))
                return;

but it *used* to do - before that commit - this:

        current->thread.kuap = KUAP_NONE;
        uaccess_end_32s(kuap);

but this all pairs with the user_read_access_begin(), which does

        allow_read_from_user(ptr, len);

which in turn is

        allow_user_access(NULL, from, size, KUAP_READ);

which again is a no-op in that book3s/32/kup.h case because KUAP_WRITE
isn't set and it returns early.

As Christophe says, there's a few 'sync()' calls sprinkled around. So
maybe the inlining and some odd compiler issue is causing problems?

Or maybe the old (incorrect) uaccess_end_32s() ended up hiding some other bug.

               Linus