From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754567AbcITVDd (ORCPT ); Tue, 20 Sep 2016 17:03:33 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:60538 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753810AbcITVDb (ORCPT ); Tue, 20 Sep 2016 17:03:31 -0400 Date: Tue, 20 Sep 2016 22:03:26 +0100 From: Al Viro To: Linus Torvalds Cc: Heiko Carstens , Martin Schwidefsky , Jan Stancek , Arnd Bergmann , Greg Ungerer , Linux Kernel Mailing List Subject: Re: [PATCH] fix fault_in_multipages_...() on architectures with no-op access_ok() Message-ID: <20160920210326.GR2356@ZenIV.linux.org.uk> References: <57E131E6.1090507@redhat.com> <20160920150657.GN2356@ZenIV.linux.org.uk> <570490469.234828.1474391501934.JavaMail.zimbra@redhat.com> <20160920190742.GP2356@ZenIV.linux.org.uk> <20160920203821.GQ2356@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 20, 2016 at 01:48:10PM -0700, Linus Torvalds wrote: > On Tue, Sep 20, 2016 at 1:38 PM, Al Viro 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.