RE: [PATCH 04/11] iov_iter: explicitly check for CHECK_IOVEC_ONLY in rw_copy_check_uvector
From: David Laight <hidden>
Date: 2020-09-21 15:05:41
Also in:
io-uring, keyrings, linux-arch, linux-arm-kernel, linux-block, linux-fsdevel, linux-mips, linux-mm, linux-s390, linux-scsi, linux-security-module, linuxppc-dev, lkml, sparclinux
From: Christoph Hellwig
quoted hunk ↗ jump to hunk
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@lst.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)