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:   Wed, 4 Apr 2018 19:40:36 -0700
From:   Linus Torvalds <>
To:     "Michael S. Tsirkin" <>
Cc:     Linux Kernel Mailing List <>,
        stable <>,,
        linux-mm <>,
        "Kirill A. Shutemov" <>,
        Andrew Morton <>,
        Huang Ying <>,
        Jonathan Corbet <>,
        Peter Zijlstra <>,
        Thomas Gleixner <>,
        Thorsten Leemhuis <>
Subject: Re: [PATCH] gup: return -EFAULT on access_ok failure

On Wed, Apr 4, 2018 at 6:53 PM, Michael S. Tsirkin <> wrote:
> Any feedback on this? As this fixes a bug in vhost, I'll merge
> through the vhost tree unless someone objects.


__get_user_pages_fast() returns the number of pages it gets.

It has never returned an error code, and all the other versions of it
(architecture-specific) don't either.

If you ask for one page, and get zero pages, then that's an -EFAULT.
Note that that's an EFAULT regardless of whether that zero page
happened due to kernel addresses or just lack of mapping in user

The documentation is simply wrong if it says anything else. Fix the
docs, and fix the users.

The correct use has always been to check the number of pages returned.

Just looking around, returning an error number looks like it could
seriously confuse some things. You have things like the kvm code that
does the *right* thing:

        unsigned long ... npinned ...

        npinned = get_user_pages_fast(uaddr, npages, write ?
FOLL_WRITE : 0, pages);
        if (npinned != npages) {

        if (npinned > 0)
                release_pages(pages, npinned);

and the above code clearly depends on the actual behavior, not on the

Any changes in this area would need some *extreme* care, exactly
because of code like the above that clearly depends on the existing

In fact, the documentation really seems to be just buggy. The actual
get_user_pages() function itself is expressly being careful *not* to
return an error code, it even has a comment to the effect ("Have to be
a bit careful with return values").

So the "If no pages were pinned, returns -errno" comment is just bogus.


Powered by blists - more mailing lists