All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Russell King - ARM Linux <linux@armlinux.org.uk>,
	"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Richard Henderson <rth@twiddle.net>,
	Will Deacon <will.deacon@arm.com>,
	Haavard Skinnemoen <hskinnemoen@gmail.com>,
	Vineet Gupta <vgupta@synopsys.com>,
	Steven Miao <realmz6@gmail.com>,
	Jesper Nilsson <jesper.nilsson@axis.com>,
	Mark Salter <msalter@redhat.com>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Richard Kuo <rkuo@codeaurora.org>,
	Tony Luck <tony.luck@intel.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	James Hogan <james.hogan@imgtec.com>,
	Michal Simek <monstr@monstr.eu>,
	David Howells <dhowells@redhat.com>,
	Ley Foon Tan <lftan@altera.com>, Jonas Bonn <jonas@southpole.se>,
	Helge Deller <deller@gmx.de>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Ralf Baechle <ralf@linux-mips.org>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Chen Liqin <liqin.linux@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	Chris Metcalf <cmetcalf@mellanox.com>,
	Richard Weinberger <richard@nod.at>,
	Guan Xuetao <gxt@mprc.pku.edu.cn>,
	Thomas Gleixner <tglx@linutronix.de>,
	Chris Zankel <chris@zankel.net>
Subject: Re: [RFC][CFT][PATCHSET v1] uaccess unification
Date: Thu, 30 Mar 2017 12:19:35 -0700	[thread overview]
Message-ID: <CA+55aFwktbgtL_x4gKqcJU6=FrkokneLRQ30HtDhuR2WErG83w@mail.gmail.com> (raw)
In-Reply-To: <20170330191009.GU29622@ZenIV.linux.org.uk>

On Thu, Mar 30, 2017 at 12:10 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> That they very definitely should not.  And not because of access_ok() or
> might_fault() - this is one place where zero-padding is absolutely wrong.
> So unless you are going to take it out of copy_from_user() and pray
> that random shit ioctls in random shit drivers check the return value
> properly, copy_from_user() is no-go here.

Actually, that is a great example of why you should *not* use
__copy_from_user().

If the reason is lack of zero-padding, that doesn't mean that suddenly
we shouldn't check the range. And it doesn't mean that it shouldn't
document why it does it.

So dammit, just add something like this to lib/iovec.c:

    static inline unsigned long copy_from_user_nozero(void *to, const
void __user *from, size_t len)
    {
        if (!access_ok(from, len))
            return len;
        return __copy_from_user(to, from, len);
    }

which now isn't insecure, and also magically documents *why* you don't
just use the plain copy_from_user().

                 Linus

WARNING: multiple messages have this Message-ID (diff)
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Russell King - ARM Linux <linux@armlinux.org.uk>,
	"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Richard Henderson <rth@twiddle.net>,
	Will Deacon <will.deacon@arm.com>,
	Haavard Skinnemoen <hskinnemoen@gmail.com>,
	Vineet Gupta <vgupta@synopsys.com>,
	Steven Miao <realmz6@gmail.com>,
	Jesper Nilsson <jesper.nilsson@axis.com>,
	Mark Salter <msalter@redhat.com>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Richard Kuo <rkuo@codeaurora.org>,
	Tony Luck <tony.luck@intel.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	James Hogan <james.hogan@imgtec.com>,
	Michal Simek <monstr@monstr.eu>,
	David Howells <dhowells@redhat.com>,
	Ley Foon Tan <lftan@altera.com>, Jonas Bonn <jonas@southpole>
Subject: Re: [RFC][CFT][PATCHSET v1] uaccess unification
Date: Thu, 30 Mar 2017 12:19:35 -0700	[thread overview]
Message-ID: <CA+55aFwktbgtL_x4gKqcJU6=FrkokneLRQ30HtDhuR2WErG83w@mail.gmail.com> (raw)
In-Reply-To: <20170330191009.GU29622@ZenIV.linux.org.uk>

On Thu, Mar 30, 2017 at 12:10 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> That they very definitely should not.  And not because of access_ok() or
> might_fault() - this is one place where zero-padding is absolutely wrong.
> So unless you are going to take it out of copy_from_user() and pray
> that random shit ioctls in random shit drivers check the return value
> properly, copy_from_user() is no-go here.

Actually, that is a great example of why you should *not* use
__copy_from_user().

If the reason is lack of zero-padding, that doesn't mean that suddenly
we shouldn't check the range. And it doesn't mean that it shouldn't
document why it does it.

So dammit, just add something like this to lib/iovec.c:

    static inline unsigned long copy_from_user_nozero(void *to, const
void __user *from, size_t len)
    {
        if (!access_ok(from, len))
            return len;
        return __copy_from_user(to, from, len);
    }

which now isn't insecure, and also magically documents *why* you don't
just use the plain copy_from_user().

                 Linus

  reply	other threads:[~2017-03-30 19:19 UTC|newest]

Thread overview: 83+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-29  5:57 [RFC][CFT][PATCHSET v1] uaccess unification Al Viro
2017-03-29  5:57 ` Al Viro
2017-03-29 20:08 ` Vineet Gupta
2017-03-29 20:08   ` Vineet Gupta
2017-03-29 20:08   ` Vineet Gupta
2017-03-29 20:29   ` Al Viro
2017-03-29 20:29     ` Al Viro
2017-03-29 20:37     ` Linus Torvalds
2017-03-29 20:37       ` Linus Torvalds
2017-03-29 21:03       ` Al Viro
2017-03-29 21:03         ` Al Viro
2017-03-29 21:24         ` Linus Torvalds
2017-03-29 21:24           ` Linus Torvalds
2017-03-29 23:09           ` Al Viro
2017-03-29 23:09             ` Al Viro
2017-03-29 23:43             ` Linus Torvalds
2017-03-29 23:43               ` Linus Torvalds
2017-03-30 15:31               ` Al Viro
2017-03-30 15:31                 ` Al Viro
2017-03-29 21:14     ` Vineet Gupta
2017-03-29 21:14       ` Vineet Gupta
2017-03-29 23:42       ` Al Viro
2017-03-29 23:42         ` Al Viro
2017-03-30  0:02         ` Vineet Gupta
2017-03-30  0:02           ` Vineet Gupta
2017-03-30  0:27           ` Linus Torvalds
2017-03-30  0:27             ` Linus Torvalds
2017-03-30  1:15             ` Al Viro
2017-03-30  1:15               ` Al Viro
2017-03-30 20:40             ` Vineet Gupta
2017-03-30 20:40               ` Vineet Gupta
2017-03-30 20:59               ` Linus Torvalds
2017-03-30 20:59                 ` Linus Torvalds
2017-03-30 23:21                 ` Russell King - ARM Linux
2017-03-30 23:21                   ` Russell King - ARM Linux
2017-03-30 12:32 ` Martin Schwidefsky
2017-03-30 12:32   ` Martin Schwidefsky
2017-03-30 14:48   ` Al Viro
2017-03-30 14:48     ` Al Viro
2017-03-30 16:22 ` Russell King - ARM Linux
2017-03-30 16:22   ` Russell King - ARM Linux
2017-03-30 16:43   ` Al Viro
2017-03-30 16:43     ` Al Viro
2017-03-30 17:18     ` Linus Torvalds
2017-03-30 17:18       ` Linus Torvalds
2017-03-30 18:48       ` Al Viro
2017-03-30 18:48         ` Al Viro
2017-03-30 18:54         ` Al Viro
2017-03-30 18:54           ` Al Viro
2017-03-30 18:59           ` Linus Torvalds
2017-03-30 18:59             ` Linus Torvalds
2017-03-30 19:10             ` Al Viro
2017-03-30 19:10               ` Al Viro
2017-03-30 19:19               ` Linus Torvalds [this message]
2017-03-30 19:19                 ` Linus Torvalds
2017-03-30 21:08                 ` Al Viro
2017-03-30 21:08                   ` Al Viro
2017-03-30 18:56         ` Linus Torvalds
2017-03-30 18:56           ` Linus Torvalds
2017-03-31  0:21 ` Kees Cook
2017-03-31  0:21   ` Kees Cook
2017-03-31 13:38   ` James Hogan
2017-03-31 13:38     ` James Hogan
2017-04-03 16:27 ` James Morse
2017-04-03 16:27   ` James Morse
2017-04-04 20:26 ` Max Filippov
2017-04-04 20:26   ` Max Filippov
2017-04-04 20:26   ` Max Filippov
2017-04-04 20:52   ` Al Viro
2017-04-04 20:52     ` Al Viro
2017-04-05  5:05 ` ia64 exceptions (Re: [RFC][CFT][PATCHSET v1] uaccess unification) Al Viro
2017-04-05  5:05   ` Al Viro
2017-04-05  8:08   ` Al Viro
2017-04-05  8:08     ` Al Viro
2017-04-05 18:44     ` Tony Luck
2017-04-05 18:44       ` Tony Luck
2017-04-05 20:33       ` Al Viro
2017-04-05 20:33         ` Al Viro
2017-04-07  0:24 ` [RFC][CFT][PATCHSET v2] uaccess unification Al Viro
2017-04-07  0:24   ` Al Viro
2017-04-07  0:35   ` Al Viro
2017-04-07  0:35     ` Al Viro
     [not found] <CACVxJT8+fQqvpSPb9rTWFy6g7moqUqxi+Ewjcg0ykuqo=vm4Ow@mail.gmail.com>
2017-03-30 13:27 ` [RFC][CFT][PATCHSET v1] " Alexey Dobriyan

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='CA+55aFwktbgtL_x4gKqcJU6=FrkokneLRQ30HtDhuR2WErG83w@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=benh@kernel.crashing.org \
    --cc=chris@zankel.net \
    --cc=cmetcalf@mellanox.com \
    --cc=davem@davemloft.net \
    --cc=deller@gmx.de \
    --cc=dhowells@redhat.com \
    --cc=geert@linux-m68k.org \
    --cc=gxt@mprc.pku.edu.cn \
    --cc=hskinnemoen@gmail.com \
    --cc=james.hogan@imgtec.com \
    --cc=jesper.nilsson@axis.com \
    --cc=jonas@southpole.se \
    --cc=lftan@altera.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=liqin.linux@gmail.com \
    --cc=monstr@monstr.eu \
    --cc=msalter@redhat.com \
    --cc=ralf@linux-mips.org \
    --cc=realmz6@gmail.com \
    --cc=richard@nod.at \
    --cc=rkuo@codeaurora.org \
    --cc=rth@twiddle.net \
    --cc=schwidefsky@de.ibm.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=vgupta@synopsys.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=will.deacon@arm.com \
    --cc=ysato@users.sourceforge.jp \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.