All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] Fix: compat_rw_copy_check_uvector() misuse in aio, readv, writev, and security keys
@ 2013-02-25 15:20 Mathieu Desnoyers
  2013-03-11 20:46 ` Greg Kroah-Hartman
  0 siblings, 1 reply; 6+ messages in thread
From: Mathieu Desnoyers @ 2013-02-25 15:20 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Greg Kroah-Hartman, Security Officers, Al Viro, stable, linux-kernel

Looking at mm/process_vm_access.c:process_vm_rw() and comparing it to
compat_process_vm_rw() shows that the compatibility code requires an
explicit "access_ok()" check before calling
compat_rw_copy_check_uvector(). The same difference seems to appear when
we compare fs/read_write.c:do_readv_writev() to
fs/compat.c:compat_do_readv_writev().

This subtle difference between the compat and non-compat requirements
should probably be debated, as it seems to be error-prone. In fact,
there are two others sites that use this function in the Linux kernel,
and they both seem to get it wrong:

Now shifting our attention to fs/aio.c, we see that aio_setup_iocb()
also ends up calling compat_rw_copy_check_uvector() through
aio_setup_vectored_rw(). Unfortunately, the access_ok() check appears to
be missing. Same situation for
security/keys/compat.c:compat_keyctl_instantiate_key_iov().

I propose that we add the access_ok() check directly into
compat_rw_copy_check_uvector(), so callers don't have to worry about it,
and it therefore makes the compat call code similar to its non-compat
counterpart. Place the access_ok() check in the same location where
copy_from_user() can trigger a -EFAULT error in the non-compat code, so
the ABI behaviors are alike on both compat and non-compat.

While we are here, fix compat_do_readv_writev() so it checks for
compat_rw_copy_check_uvector() negative return values.

And also, fix a memory leak in compat_keyctl_instantiate_key_iov() error
handling.

Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Acked-by: Al Viro <viro@ZenIV.linux.org.uk>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
---
 fs/compat.c            |   15 +++++++--------
 mm/process_vm_access.c |    8 --------
 security/keys/compat.c |    4 ++--
 3 files changed, 9 insertions(+), 18 deletions(-)

Index: linux/fs/compat.c
===================================================================
--- linux.orig/fs/compat.c
+++ linux/fs/compat.c
@@ -558,6 +558,10 @@ ssize_t compat_rw_copy_check_uvector(int
 	}
 	*ret_pointer = iov;
 
+	ret = -EFAULT;
+	if (!access_ok(VERIFY_READ, uvector, nr_segs*sizeof(*uvector)))
+		goto out;
+
 	/*
 	 * Single unix specification:
 	 * We should -EINVAL if an element length is not >= 0 and fitting an
@@ -1080,17 +1084,12 @@ static ssize_t compat_do_readv_writev(in
 	if (!file->f_op)
 		goto out;
 
-	ret = -EFAULT;
-	if (!access_ok(VERIFY_READ, uvector, nr_segs*sizeof(*uvector)))
-		goto out;
-
-	tot_len = compat_rw_copy_check_uvector(type, uvector, nr_segs,
+	ret = compat_rw_copy_check_uvector(type, uvector, nr_segs,
 					       UIO_FASTIOV, iovstack, &iov);
-	if (tot_len == 0) {
-		ret = 0;
+	if (ret <= 0)
 		goto out;
-	}
 
+	tot_len = ret;
 	ret = rw_verify_area(type, file, pos, tot_len);
 	if (ret < 0)
 		goto out;
Index: linux/mm/process_vm_access.c
===================================================================
--- linux.orig/mm/process_vm_access.c
+++ linux/mm/process_vm_access.c
@@ -429,12 +429,6 @@ compat_process_vm_rw(compat_pid_t pid,
 	if (flags != 0)
 		return -EINVAL;
 
-	if (!access_ok(VERIFY_READ, lvec, liovcnt * sizeof(*lvec)))
-		goto out;
-
-	if (!access_ok(VERIFY_READ, rvec, riovcnt * sizeof(*rvec)))
-		goto out;
-
 	if (vm_write)
 		rc = compat_rw_copy_check_uvector(WRITE, lvec, liovcnt,
 						  UIO_FASTIOV, iovstack_l,
@@ -459,8 +453,6 @@ free_iovecs:
 		kfree(iov_r);
 	if (iov_l != iovstack_l)
 		kfree(iov_l);
-
-out:
 	return rc;
 }
 
Index: linux/security/keys/compat.c
===================================================================
--- linux.orig/security/keys/compat.c
+++ linux/security/keys/compat.c
@@ -40,12 +40,12 @@ static long compat_keyctl_instantiate_ke
 					   ARRAY_SIZE(iovstack),
 					   iovstack, &iov);
 	if (ret < 0)
-		return ret;
+		goto err;
 	if (ret == 0)
 		goto no_payload_free;
 
 	ret = keyctl_instantiate_key_common(id, iov, ioc, ret, ringid);
-
+err:
 	if (iov != iovstack)
 		kfree(iov);
 	return ret;
-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] Fix: compat_rw_copy_check_uvector() misuse in aio, readv, writev, and security keys
  2013-02-25 15:20 [PATCH] Fix: compat_rw_copy_check_uvector() misuse in aio, readv, writev, and security keys Mathieu Desnoyers
@ 2013-03-11 20:46 ` Greg Kroah-Hartman
  2013-03-11 20:53   ` Mathieu Desnoyers
  0 siblings, 1 reply; 6+ messages in thread
From: Greg Kroah-Hartman @ 2013-03-11 20:46 UTC (permalink / raw)
  To: Mathieu Desnoyers
  Cc: Linus Torvalds, Security Officers, Al Viro, stable, linux-kernel

On Mon, Feb 25, 2013 at 10:20:36AM -0500, Mathieu Desnoyers wrote:
> Looking at mm/process_vm_access.c:process_vm_rw() and comparing it to
> compat_process_vm_rw() shows that the compatibility code requires an
> explicit "access_ok()" check before calling
> compat_rw_copy_check_uvector(). The same difference seems to appear when
> we compare fs/read_write.c:do_readv_writev() to
> fs/compat.c:compat_do_readv_writev().
> 
> This subtle difference between the compat and non-compat requirements
> should probably be debated, as it seems to be error-prone. In fact,
> there are two others sites that use this function in the Linux kernel,
> and they both seem to get it wrong:
> 
> Now shifting our attention to fs/aio.c, we see that aio_setup_iocb()
> also ends up calling compat_rw_copy_check_uvector() through
> aio_setup_vectored_rw(). Unfortunately, the access_ok() check appears to
> be missing. Same situation for
> security/keys/compat.c:compat_keyctl_instantiate_key_iov().
> 
> I propose that we add the access_ok() check directly into
> compat_rw_copy_check_uvector(), so callers don't have to worry about it,
> and it therefore makes the compat call code similar to its non-compat
> counterpart. Place the access_ok() check in the same location where
> copy_from_user() can trigger a -EFAULT error in the non-compat code, so
> the ABI behaviors are alike on both compat and non-compat.
> 
> While we are here, fix compat_do_readv_writev() so it checks for
> compat_rw_copy_check_uvector() negative return values.
> 
> And also, fix a memory leak in compat_keyctl_instantiate_key_iov() error
> handling.
> 
> Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
> Acked-by: Al Viro <viro@ZenIV.linux.org.uk>
> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> ---
>  fs/compat.c            |   15 +++++++--------
>  mm/process_vm_access.c |    8 --------
>  security/keys/compat.c |    4 ++--
>  3 files changed, 9 insertions(+), 18 deletions(-)

What ever happened to this patch?  I don't see it in Linus's tree, was
it not correct?

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] Fix: compat_rw_copy_check_uvector() misuse in aio, readv, writev, and security keys
  2013-03-11 20:46 ` Greg Kroah-Hartman
@ 2013-03-11 20:53   ` Mathieu Desnoyers
  2013-03-12 18:04     ` Linus Torvalds
  0 siblings, 1 reply; 6+ messages in thread
From: Mathieu Desnoyers @ 2013-03-11 20:53 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Linus Torvalds, Security Officers, Al Viro, stable, linux-kernel

* Greg Kroah-Hartman (gregkh@linuxfoundation.org) wrote:
> On Mon, Feb 25, 2013 at 10:20:36AM -0500, Mathieu Desnoyers wrote:
> > Looking at mm/process_vm_access.c:process_vm_rw() and comparing it to
> > compat_process_vm_rw() shows that the compatibility code requires an
> > explicit "access_ok()" check before calling
> > compat_rw_copy_check_uvector(). The same difference seems to appear when
> > we compare fs/read_write.c:do_readv_writev() to
> > fs/compat.c:compat_do_readv_writev().
> > 
> > This subtle difference between the compat and non-compat requirements
> > should probably be debated, as it seems to be error-prone. In fact,
> > there are two others sites that use this function in the Linux kernel,
> > and they both seem to get it wrong:
> > 
> > Now shifting our attention to fs/aio.c, we see that aio_setup_iocb()
> > also ends up calling compat_rw_copy_check_uvector() through
> > aio_setup_vectored_rw(). Unfortunately, the access_ok() check appears to
> > be missing. Same situation for
> > security/keys/compat.c:compat_keyctl_instantiate_key_iov().
> > 
> > I propose that we add the access_ok() check directly into
> > compat_rw_copy_check_uvector(), so callers don't have to worry about it,
> > and it therefore makes the compat call code similar to its non-compat
> > counterpart. Place the access_ok() check in the same location where
> > copy_from_user() can trigger a -EFAULT error in the non-compat code, so
> > the ABI behaviors are alike on both compat and non-compat.
> > 
> > While we are here, fix compat_do_readv_writev() so it checks for
> > compat_rw_copy_check_uvector() negative return values.
> > 
> > And also, fix a memory leak in compat_keyctl_instantiate_key_iov() error
> > handling.
> > 
> > Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
> > Acked-by: Al Viro <viro@ZenIV.linux.org.uk>
> > Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> > ---
> >  fs/compat.c            |   15 +++++++--------
> >  mm/process_vm_access.c |    8 --------
> >  security/keys/compat.c |    4 ++--
> >  3 files changed, 9 insertions(+), 18 deletions(-)
> 
> What ever happened to this patch?  I don't see it in Linus's tree, was
> it not correct?

Not sure. My guess would be that there is missing proof that I actually
tested the patch by generating a OOPS splat and proof that it actually
fixes it. I mainly tested that it does not break _correct_ use of aio,
but I did not have enough time to created my own custom aio lib to
generate the issue. So if this is what is expected, I might need a bit
of help on this front. Testing odd behavior through libaio proved to
non-straightforward.

Thoughts ?

Thanks,

Mathieu

> 
> thanks,
> 
> greg k-h

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] Fix: compat_rw_copy_check_uvector() misuse in aio, readv, writev, and security keys
  2013-03-11 20:53   ` Mathieu Desnoyers
@ 2013-03-12 18:04     ` Linus Torvalds
  2013-03-12 18:23       ` Linus Torvalds
  0 siblings, 1 reply; 6+ messages in thread
From: Linus Torvalds @ 2013-03-12 18:04 UTC (permalink / raw)
  To: Mathieu Desnoyers
  Cc: Greg Kroah-Hartman, Security Officers, Al Viro, stable,
	Linux Kernel Mailing List

On Mon, Mar 11, 2013 at 1:53 PM, Mathieu Desnoyers
<mathieu.desnoyers@efficios.com> wrote:
>
> Not sure. My guess would be that there is missing proof that I actually
> tested the patch

Well, it was actually mostly that the early patches I saw had very
tentative messages which made me go "Mathieu isn't sure" and kind of
waited for more forceful messages and acks from people. It wasn't
helped by the fact that Al was basically offline for a while.

That said, the patch definitely looks like the right thing to do. I'll apply it.

              Linus

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] Fix: compat_rw_copy_check_uvector() misuse in aio, readv, writev, and security keys
  2013-03-12 18:04     ` Linus Torvalds
@ 2013-03-12 18:23       ` Linus Torvalds
  2013-03-13 13:53         ` Mathieu Desnoyers
  0 siblings, 1 reply; 6+ messages in thread
From: Linus Torvalds @ 2013-03-12 18:23 UTC (permalink / raw)
  To: Mathieu Desnoyers
  Cc: Greg Kroah-Hartman, Security Officers, Al Viro, stable,
	Linux Kernel Mailing List

On Tue, Mar 12, 2013 at 11:04 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> That said, the patch definitely looks like the right thing to do. I'll apply it.

Hmm. I applied it, and then pretty much immediately realized what was
problematic about it. What about the fs/bio.c one?  This all felt like
it was still a work-in-progress, and I'm not sure if you had more
comments or patches coming along?

Anyway, this particular patch got applied. Does that obviate the need
for the fs/bio.c one? I didn't follow all the call-chains...

                   Linus

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] Fix: compat_rw_copy_check_uvector() misuse in aio, readv, writev, and security keys
  2013-03-12 18:23       ` Linus Torvalds
@ 2013-03-13 13:53         ` Mathieu Desnoyers
  0 siblings, 0 replies; 6+ messages in thread
From: Mathieu Desnoyers @ 2013-03-13 13:53 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Greg Kroah-Hartman, Security Officers, Al Viro, stable,
	Linux Kernel Mailing List

* Linus Torvalds (torvalds@linux-foundation.org) wrote:
> On Tue, Mar 12, 2013 at 11:04 AM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > That said, the patch definitely looks like the right thing to do. I'll apply it.
> 
> Hmm. I applied it, and then pretty much immediately realized what was
> problematic about it. What about the fs/bio.c one?  This all felt like
> it was still a work-in-progress, and I'm not sure if you had more
> comments or patches coming along?
> 
> Anyway, this particular patch got applied. Does that obviate the need
> for the fs/bio.c one? I didn't follow all the call-chains...

The fs/bio.c issue is unrelated to this patch, so that separate issue
still stands. I did not get any feedback on that private RFC though.

Should I repost it CCing lkml ?

Thanks,

Mathieu


-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2013-03-13 13:53 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-02-25 15:20 [PATCH] Fix: compat_rw_copy_check_uvector() misuse in aio, readv, writev, and security keys Mathieu Desnoyers
2013-03-11 20:46 ` Greg Kroah-Hartman
2013-03-11 20:53   ` Mathieu Desnoyers
2013-03-12 18:04     ` Linus Torvalds
2013-03-12 18:23       ` Linus Torvalds
2013-03-13 13:53         ` Mathieu Desnoyers

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.