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 <h...@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)
