From: Al Viro <viro@ZenIV.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>,
Martin Schwidefsky <schwidefsky@de.ibm.com>,
Jan Stancek <jstancek@redhat.com>, Arnd Bergmann <arnd@arndb.de>,
Greg Ungerer <gerg@uclinux.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] fix fault_in_multipages_...() on architectures with no-op access_ok()
Date: Tue, 20 Sep 2016 22:03:26 +0100 [thread overview]
Message-ID: <20160920210326.GR2356@ZenIV.linux.org.uk> (raw)
In-Reply-To: <CA+55aFxZbjiHBjdwZ46eHYe12kkY_44y2cFAMAufzmv_nO+NEA@mail.gmail.com>
On Tue, Sep 20, 2016 at 01:48:10PM -0700, Linus Torvalds wrote:
> On Tue, Sep 20, 2016 at 1:38 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> >
> > Not the point. Of course it *would* fail; the problem is that the loop
> > that would ping each page is never executed.
>
> You're missing the point.
>
> If "access_ok()" is fine with wrapping, then some otehr system call
> that wraps will successfully do a memcpy_from/to_user() with a wrapped
> address (and the proper mappings).
What proper mappings? If you manage to mmap something at (void*)-PAGE_SIZE,
you are very deep in trouble regardless. We use IS_ERR() on userland
pointers and any architecture where that would be possible would be confused
as hell.
The testcase here is uaddr = (void *)-1, len = (unsigned long)valid_addr + 2.
If it tried to do __put_user(uaddr, 0) it would immediately fail, just as
__copy_to_user(uaddr, len); the problem is, that call will only do
__put_user(valid_addr, 0) and succeed.
Again, if get_user/put_user/copy_{to,from}_user() anywhere near ERR_PTR(...)
would succeed, we'd get trouble without any wraparounds. That page should
be absent, and it really is. In all cases, s390 included. Wraparound is
irrelevant here. The reason why it got spotted was persistent failure of
copy_{to,from}_user after successful fault-ins.
next prev parent reply other threads:[~2016-09-20 21:03 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-20 12:56 [bug] pwritev02 hang on s390x with 4.8.0-rc7 Jan Stancek
2016-09-20 15:06 ` Al Viro
2016-09-20 17:11 ` Jan Stancek
2016-09-20 17:30 ` Al Viro
2016-09-20 19:07 ` [PATCH] fix fault_in_multipages_...() on architectures with no-op access_ok() Al Viro
2016-09-20 20:24 ` Linus Torvalds
2016-09-20 20:38 ` Al Viro
2016-09-20 20:48 ` Linus Torvalds
2016-09-20 21:03 ` Al Viro [this message]
2016-09-20 21:37 ` Al Viro
2016-09-20 23:43 ` Linus Torvalds
2016-09-21 0:38 ` Al Viro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160920210326.GR2356@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=arnd@arndb.de \
--cc=gerg@uclinux.org \
--cc=heiko.carstens@de.ibm.com \
--cc=jstancek@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=schwidefsky@de.ibm.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).