Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1735415 > unrolled thread

[PATCH] mpt3sas: downgrade full copy_from_user to access_ok check

Started byMeng Xu <mengxu.gatech@gmail.com>
First post2017-09-20 05:20 +0200
Last post2017-09-21 05:40 +0200
Articles 4 — 3 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH] mpt3sas: downgrade full copy_from_user to access_ok check Meng Xu <mengxu.gatech@gmail.com> - 2017-09-20 05:20 +0200
    Re: [PATCH] mpt3sas: downgrade full copy_from_user to access_ok check Christoph Hellwig <hch@infradead.org> - 2017-09-20 17:10 +0200
    Re: [PATCH] mpt3sas: downgrade full copy_from_user to access_ok check Al Viro <viro@ZenIV.linux.org.uk> - 2017-09-21 05:30 +0200
      Re: [PATCH] mpt3sas: downgrade full copy_from_user to access_ok check Meng Xu <mengxu.gatech@gmail.com> - 2017-09-21 05:40 +0200

#1735415 — [PATCH] mpt3sas: downgrade full copy_from_user to access_ok check

FromMeng Xu <mengxu.gatech@gmail.com>
Date2017-09-20 05:20 +0200
Subject[PATCH] mpt3sas: downgrade full copy_from_user to access_ok check
Message-ID<urDIl-5IT-11@gated-at.bofh.it>
Since right after the user copy, we are going to
memset(&karg, 0, sizeof(karg)), I guess an access_ok check is enough?

Signed-off-by: Meng Xu <mengxu.gatech@gmail.com>
---
 drivers/scsi/mpt3sas/mpt3sas_ctl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_ctl.c b/drivers/scsi/mpt3sas/mpt3sas_ctl.c
index bdffb69..b363d2d 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_ctl.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_ctl.c
@@ -1065,7 +1065,7 @@ _ctl_getiocinfo(struct MPT3SAS_ADAPTER *ioc, void __user *arg)
 {
 	struct mpt3_ioctl_iocinfo karg;
 
-	if (copy_from_user(&karg, arg, sizeof(karg))) {
+	if (!access_ok(VERIFY_READ, arg, sizeof(karg))) {
 		pr_err("failure at %s:%d/%s()!\n",
 		    __FILE__, __LINE__, __func__);
 		return -EFAULT;
-- 
2.7.4

[toc] | [next] | [standalone]


#1735819

FromChristoph Hellwig <hch@infradead.org>
Date2017-09-20 17:10 +0200
Message-ID<urONs-4IC-13@gated-at.bofh.it>
In reply to#1735415
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?

The right thing is to remove it entirely.

[toc] | [prev] | [next] | [standalone]


#1736342

FromAl Viro <viro@ZenIV.linux.org.uk>
Date2017-09-21 05:30 +0200
Message-ID<us0lz-3Je-1@gated-at.bofh.it>
In reply to#1735415
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.

[toc] | [prev] | [next] | [standalone]


#1736345

FromMeng Xu <mengxu.gatech@gmail.com>
Date2017-09-21 05:40 +0200
Message-ID<us0vf-3MA-1@gated-at.bofh.it>
In reply to#1736342
> On Sep 20, 2017, at 11:26 PM, Al Viro <viro@ZenIV.linux.org.uk> wrote:
> 
> 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.

Yes, Christoph has suggested the same thing and I have submitted 
another patch with copy_from_user removed entirely.

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web