linux-kernel - Re: [PATCH] futex: improve user space accesses

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: <CAHk-=wjnvFU3sMjjKyqtgvPe6EMu3M4f1qyZncJR5=QDQsV=ng@mail.gmail.com>
Date: Sun, 8 Dec 2024 16:32:33 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Andreas Schwab <schwab@...ux-m68k.org>
Cc: Josh Poimboeuf <jpoimboe@...nel.org>, LKML <linux-kernel@...r.kernel.org>, x86@...nel.org, 
	linuxppc-dev@...ts.ozlabs.org
Subject: Re: [PATCH] futex: improve user space accesses

On Sun, 8 Dec 2024 at 14:54, Andreas Schwab <schwab@...ux-m68k.org> wrote:
>
> This breaks userspace on ppc32.  As soon as /init in the initrd is
> started the kernel hangs (without any messages).

Funky, funky. Most of the diff is the code movement (and some small
x86-specific stuff), so for ppc, the only part that should be relevant
is the futex_get_value_locked().

And since ppc doesn't do the masked user access thing, so it
*literally* boils down to just that

        if (!user_read_access_begin(from, sizeof(*from)))
                return -EFAULT;
        unsafe_get_user(val, from, Efault);
        user_access_end();

path.

Ahh... And now that I write that out, the bug is obvious: it should be using

        user_read_access_end();

to match up with the user_read_access_begin().

And yeah, ppc is the only platform that has that
"read-vs-write-vs-both" thing, so this bug is not visible anywhere
else.

IOW, does this one-liner fix it for you?

  --- a/kernel/futex/futex.h
  +++ b/kernel/futex/futex.h
  @@ -265,7 +265,7 @@
        else if (!user_read_access_begin(from, sizeof(*from)))
                return -EFAULT;
        unsafe_get_user(val, from, Efault);
  -     user_access_end();
  +     user_read_access_end();
        *dest = val;
        return 0;
   Efault:

I bet it does, but I'll wait for confirmation before actually
committing that fix.

Thanks,

                Linus