linux-kernel - Re: [PATCH] fix fault_in_multipages_...() on architectures with no-op access

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]

Date:   Tue, 20 Sep 2016 13:24:25 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Al Viro <viro@...iv.linux.org.uk>,
        Heiko Carstens <heiko.carstens@...ibm.com>,
        Martin Schwidefsky <schwidefsky@...ibm.com>,
        Jan Stancek <jstancek@...hat.com>,
        Arnd Bergmann <arnd@...db.de>, Greg Ungerer <gerg@...inux.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] fix fault_in_multipages_...() on architectures with no-op access_ok()

On Tue, Sep 20, 2016 at 12:07 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
> Switching iov_iter fault-in to multipages variants has exposed an old
> bug in underlying fault_in_multipages_...(); they break if the range
> passed to them wraps around.  Normally access_ok() done by callers
> will prevent such (and it's a guaranteed EFAULT - ERR_PTR() values
> fall into such a range and they should not point to any valid objects).
> However, on architectures where userland and kernel live in different
> MMU contexts (e.g. s390) access_ok() is a no-op and on those a range
> with a wraparound can reach fault_in_multipages_...().

Quite frankly, I think it is access_ok() that should be fixed for s390.

A wrapping user access is *not* ok, not even if kernel and user memory
are separate.

It is insane to make fault_in_multipages..() return EFAULT if a normal
wrapping user access wouldn't. So the fix is not to change
fault_in_multipage_xyz, but to make sure any op that tries to wrap
will properly return EFAULT.

So I really think that we should just say "a no-op access_ok() is a
buggy access_ok()", and fix the problem at the source, rather than
make excuses for it in some random place.

A quick look seems to say that s390 and no-mmu ARM are the only
affected cases, but maybe I missed something.

              Linus