[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7336624280b8444fb4cb00407317741b@AcuMS.aculab.com>
Date: Mon, 21 Sep 2020 15:05:32 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Christoph Hellwig' <hch@....de>,
Alexander Viro <viro@...iv.linux.org.uk>
CC: Andrew Morton <akpm@...ux-foundation.org>,
Jens Axboe <axboe@...nel.dk>, Arnd Bergmann <arnd@...db.de>,
David Howells <dhowells@...hat.com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
"linux-parisc@...r.kernel.org" <linux-parisc@...r.kernel.org>,
"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
"linux-s390@...r.kernel.org" <linux-s390@...r.kernel.org>,
"sparclinux@...r.kernel.org" <sparclinux@...r.kernel.org>,
"linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
"linux-aio@...ck.org" <linux-aio@...ck.org>,
"io-uring@...r.kernel.org" <io-uring@...r.kernel.org>,
"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"keyrings@...r.kernel.org" <keyrings@...r.kernel.org>,
"linux-security-module@...r.kernel.org"
<linux-security-module@...r.kernel.org>
Subject: RE: [PATCH 04/11] iov_iter: explicitly check for CHECK_IOVEC_ONLY in
rw_copy_check_uvector
From: Christoph Hellwig
> Sent: 21 September 2020 15:34
>
> Explicitly check for the magic value insted of implicitly relying on
> its numeric representation. Also drop the rather pointless unlikely
> annotation.
>
> Signed-off-by: Christoph Hellwig <hch@....de>
> ---
> lib/iov_iter.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/lib/iov_iter.c b/lib/iov_iter.c
> index d7e72343c360eb..a64867501a7483 100644
> --- a/lib/iov_iter.c
> +++ b/lib/iov_iter.c
> @@ -1709,8 +1709,7 @@ static ssize_t rw_copy_check_uvector(int type,
> ret = -EINVAL;
> goto out;
> }
> - if (type >= 0
> - && unlikely(!access_ok(buf, len))) {
> + if (type != CHECK_IOVEC_ONLY && !access_ok(buf, len)) {
> ret = -EFAULT;
> goto out;
> }
> @@ -1824,7 +1823,7 @@ static ssize_t compat_rw_copy_check_uvector(int type,
> }
> if (len < 0) /* size_t not fitting in compat_ssize_t .. */
> goto out;
> - if (type >= 0 &&
> + if (type != CHECK_IOVEC_ONLY &&
> !access_ok(compat_ptr(buf), len)) {
> ret = -EFAULT;
> goto out;
> --
> 2.28.0
I've actually no idea:
1) Why there is an access_ok() check here.
It will be repeated by the user copy functions.
2) Why it isn't done when called from mm/process_vm_access.c.
Ok, the addresses refer to a different process, but they
must still be valid user addresses.
Is 2 a legacy from when access_ok() actually checked that the
addresses were mapped into the process's address space?
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists