From: Al Viro <viro@ZenIV.linux.org.uk>
To: Meng Xu <mengxu.gatech@gmail.com>
Cc: sathya.prakash@broadcom.com, chaitra.basappa@broadcom.com,
suganath-prabu.subramani@broadcom.com, jejb@linux.vnet.ibm.com,
martin.petersen@oracle.com, MPT-FusionLinux.pdl@broadcom.com,
linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
meng.xu@gatech.edu, sanidhya@gatech.edu, taesoo@gatech.edu
Subject: Re: [PATCH] mpt3sas: downgrade full copy_from_user to access_ok check
Date: Thu, 21 Sep 2017 04:26:05 +0100 [thread overview]
Message-ID: <20170921032604.GF32076@ZenIV.linux.org.uk> (raw)
In-Reply-To: <1505877071-76996-1-git-send-email-mengxu.gatech@gmail.com>
On Tue, Sep 19, 2017 at 11:11:11PM -0400, Meng Xu wrote:
> Since right after the user copy, we are going to
> memset(&karg, 0, sizeof(karg)), I guess an access_ok check is enough?
access_ok() is *NOT* "will copy_from_user() succeed?" Not even close.
On a bunch of architectures (sparc64, for one) access_ok() is always
true.
All it does is checking that address is not a kernel one - e.g. on
i386 anything in range 0..3Gb qualifies. Whether anything's mapped
at that address or not.
Why bother with that copy_from_user() at all? The same ioctl()
proceeds to copy_to_user() on exact same range; all you get from
it is "if the area passed by caller is writable, but not readable,
fail with -EFAULT". Who cares?
Just drop that copy_from_user() completely. Anything access_ok()
might've caught will be caught by copy_to_user() anyway.
next prev parent reply other threads:[~2017-09-21 3:26 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-20 3:11 [PATCH] mpt3sas: downgrade full copy_from_user to access_ok check Meng Xu
2017-09-20 15:04 ` Christoph Hellwig
2017-09-21 3:26 ` Al Viro [this message]
2017-09-21 3:32 ` Meng Xu
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=20170921032604.GF32076@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=MPT-FusionLinux.pdl@broadcom.com \
--cc=chaitra.basappa@broadcom.com \
--cc=jejb@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=meng.xu@gatech.edu \
--cc=mengxu.gatech@gmail.com \
--cc=sanidhya@gatech.edu \
--cc=sathya.prakash@broadcom.com \
--cc=suganath-prabu.subramani@broadcom.com \
--cc=taesoo@gatech.edu \
/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.