LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* Linux 2.6.22.18
@ 2008-02-11  7:43 Greg Kroah-Hartman
  2008-02-11  7:43 ` Greg Kroah-Hartman
  0 siblings, 1 reply; 7+ messages in thread
From: Greg Kroah-Hartman @ 2008-02-11  7:43 UTC (permalink / raw)
  To: linux-kernel, Andrew Morton, torvalds, stable

We (the -stable team) are announcing the release of the 2.6.22.18
kernel.

It fixes one thing, CVE-2008-0600.

All users of the 2.6.22 series, with untrusted local users are strongly
encouraged to upgrade.

I'll also be replying to this message with a copy of the patch between
2.6.22.17 and 2.6.22.18

The updated 2.6.22.y git tree can be found at:
        git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.22.y.git
and can be browsed at the normal kernel.org git web browser:
        http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.22.y.git;a=summary

thanks,

greg k-h

--------

 Makefile    |    2 +-
 fs/splice.c |    3 +++
 2 files changed, 4 insertions(+), 1 deletion(-)

Summary of changes from v2.6.22.17 to v2.6.22.18
================================================

Bastian Blank (1):
      splice: fix user pointer access in get_iovec_page_array() (CVE-2008-0600)

Greg Kroah-Hartman (1):
      Linux 2.6.22.18


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

* Re: Linux 2.6.22.18
  2008-02-11  7:43 Linux 2.6.22.18 Greg Kroah-Hartman
@ 2008-02-11  7:43 ` Greg Kroah-Hartman
  2008-02-11 11:31   ` Matthew Keenan
  0 siblings, 1 reply; 7+ messages in thread
From: Greg Kroah-Hartman @ 2008-02-11  7:43 UTC (permalink / raw)
  To: linux-kernel, Andrew Morton, torvalds, stable

diff --git a/Makefile b/Makefile
index 6a949eb..99c5e87 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
 VERSION = 2
 PATCHLEVEL = 6
 SUBLEVEL = 22
-EXTRAVERSION = .17
+EXTRAVERSION = .18
 NAME = Holy Dancing Manatees, Batman!
 
 # *DOCUMENTATION*
diff --git a/fs/splice.c b/fs/splice.c
index e263d3b..dbbe267 100644
--- a/fs/splice.c
+++ b/fs/splice.c
@@ -1182,6 +1182,9 @@ static int get_iovec_page_array(const struct iovec __user *iov,
 		if (unlikely(!base))
 			break;
 
+		if (!access_ok(VERIFY_READ, base, len))
+			break;
+
 		/*
 		 * Get this base offset and number of pages, then map
 		 * in the user pages.

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

* Re: Linux 2.6.22.18
  2008-02-11  7:43 ` Greg Kroah-Hartman
@ 2008-02-11 11:31   ` Matthew Keenan
  2008-02-11 15:45     ` Greg KH
  2008-02-11 16:32     ` Linus Torvalds
  0 siblings, 2 replies; 7+ messages in thread
From: Matthew Keenan @ 2008-02-11 11:31 UTC (permalink / raw)
  To: Greg Kroah-Hartman; +Cc: linux-kernel, Andrew Morton, torvalds, stable


On Sun, 2008-02-10 at 23:43 -0800, Greg Kroah-Hartman wrote:
> diff --git a/Makefile b/Makefile
> index 6a949eb..99c5e87 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1,7 +1,7 @@
>  VERSION = 2
>  PATCHLEVEL = 6
>  SUBLEVEL = 22
> -EXTRAVERSION = .17
> +EXTRAVERSION = .18
>  NAME = Holy Dancing Manatees, Batman!
>  
>  # *DOCUMENTATION*
> diff --git a/fs/splice.c b/fs/splice.c
> index e263d3b..dbbe267 100644
> --- a/fs/splice.c
> +++ b/fs/splice.c
> @@ -1182,6 +1182,9 @@ static int get_iovec_page_array(const struct iovec __user *iov,
>  		if (unlikely(!base))
>  			break;
>  
> +		if (!access_ok(VERIFY_READ, base, len))
> +			break;
> +
>  		/*
>  		 * Get this base offset and number of pages, then map
>  		 * in the user pages.

Maybe I'm missing something here, but is there are reason that the patch
for 2.6.22 differs from 2.6.2[34]? The "if(unlikely(!base))" is removed
in the latter.

Matt



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

* Re: Linux 2.6.22.18
  2008-02-11 11:31   ` Matthew Keenan
@ 2008-02-11 15:45     ` Greg KH
  2008-02-12 17:48       ` Florian Weimer
  2008-02-11 16:32     ` Linus Torvalds
  1 sibling, 1 reply; 7+ messages in thread
From: Greg KH @ 2008-02-11 15:45 UTC (permalink / raw)
  To: Matthew Keenan; +Cc: linux-kernel, Andrew Morton, torvalds, stable

On Mon, Feb 11, 2008 at 11:31:25AM +0000, Matthew Keenan wrote:
> 
> On Sun, 2008-02-10 at 23:43 -0800, Greg Kroah-Hartman wrote:
> > diff --git a/Makefile b/Makefile
> > index 6a949eb..99c5e87 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -1,7 +1,7 @@
> >  VERSION = 2
> >  PATCHLEVEL = 6
> >  SUBLEVEL = 22
> > -EXTRAVERSION = .17
> > +EXTRAVERSION = .18
> >  NAME = Holy Dancing Manatees, Batman!
> >  
> >  # *DOCUMENTATION*
> > diff --git a/fs/splice.c b/fs/splice.c
> > index e263d3b..dbbe267 100644
> > --- a/fs/splice.c
> > +++ b/fs/splice.c
> > @@ -1182,6 +1182,9 @@ static int get_iovec_page_array(const struct iovec __user *iov,
> >  		if (unlikely(!base))
> >  			break;
> >  
> > +		if (!access_ok(VERIFY_READ, base, len))
> > +			break;
> > +
> >  		/*
> >  		 * Get this base offset and number of pages, then map
> >  		 * in the user pages.
> 
> Maybe I'm missing something here, but is there are reason that the patch
> for 2.6.22 differs from 2.6.2[34]? The "if(unlikely(!base))" is removed
> in the latter.

the logic is a little different in 2.6.22 and earlier in regards to this
area of code.  This way we are safer.

thanks,

greg k-h

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

* Re: Linux 2.6.22.18
  2008-02-11 11:31   ` Matthew Keenan
  2008-02-11 15:45     ` Greg KH
@ 2008-02-11 16:32     ` Linus Torvalds
  1 sibling, 0 replies; 7+ messages in thread
From: Linus Torvalds @ 2008-02-11 16:32 UTC (permalink / raw)
  To: Matthew Keenan; +Cc: Greg Kroah-Hartman, linux-kernel, Andrew Morton, stable



On Mon, 11 Feb 2008, Matthew Keenan wrote:
> 
> Maybe I'm missing something here, but is there are reason that the patch
> for 2.6.22 differs from 2.6.2[34]? The "if(unlikely(!base))" is removed
> in the latter.

No real reason, except that there are simply two versions of the patches 
floating around: the original (that added the "access_ok()"), and the one 
I actually applied to the development tree (in which I hand-edited the 
patch to remove the old "!base" comparison, since I thought that one was 
just wrong).

Which one you prefer is probably a matter of taste, and which one you 
ended up picking up is probably a matter of just luck. They are basically 
the same, with the only difference being whether you think NULL is special 
or not. I don't personally think it should be, and if people want to put 
data at their linear address zero, they may have reasons for it (vm86 mode 
is one such reason, things like wine might be another - basically some 
environments may have legacy reasons to think that address 0 can be 
something else than just NULL).

For any *normal* program, this should be totally immaterial, since address 
0 won't be mapped, and you'll just take an EFAULT later. And from the 
security standpoint in this particular case, address 0 is a perfectly 
normal user address, so there is nothing special about it.

[ What _is_ special about address 0 is that if the kernel forgets some 
  NULL pointer check, we'd want to see an oops, not a user space access. 

  But that's really a totally different class of bug, and quite frankly, 
  if you want to disallow people mmap'ing at offset zero, it's an mmap() 
  issue, not anything else. See the new SECURITY_DEFAULT_MMAP_MIN_ADDR 
  thing for that. ]

In this particular case, maybe some -stable person might have felt that 
they just didn't want to change semantics for the NULL pointer, or maybe 
they didn't even notice that what I committed to the development tree was 
slightly changed. It _really_ doesn't matter.

			Linus

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

* Re: Linux 2.6.22.18
  2008-02-11 15:45     ` Greg KH
@ 2008-02-12 17:48       ` Florian Weimer
  2008-02-12 17:50         ` Greg KH
  0 siblings, 1 reply; 7+ messages in thread
From: Florian Weimer @ 2008-02-12 17:48 UTC (permalink / raw)
  To: Greg KH; +Cc: Matthew Keenan, linux-kernel, Andrew Morton, torvalds, stable

* Greg KH:

> the logic is a little different in 2.6.22 and earlier in regards to this
> area of code.  This way we are safer.

Your patch doesn't include the CVE-2006-0010 hunk.  Is this because
get_user() implies an access_ok() check (while __copy_from_user()
obviously does not)?

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

* Re: Linux 2.6.22.18
  2008-02-12 17:48       ` Florian Weimer
@ 2008-02-12 17:50         ` Greg KH
  0 siblings, 0 replies; 7+ messages in thread
From: Greg KH @ 2008-02-12 17:50 UTC (permalink / raw)
  To: Florian Weimer
  Cc: Matthew Keenan, linux-kernel, Andrew Morton, torvalds, stable

On Tue, Feb 12, 2008 at 06:48:42PM +0100, Florian Weimer wrote:
> * Greg KH:
> 
> > the logic is a little different in 2.6.22 and earlier in regards to this
> > area of code.  This way we are safer.
> 
> Your patch doesn't include the CVE-2006-0010 hunk.  Is this because
> get_user() implies an access_ok() check (while __copy_from_user()
> obviously does not)?

Yes, that is exactly why.  CVE-2006-0010 and -0009 are not applicable to
kernels prior to 2.6.23.

thanks,

greg k-h

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

end of thread, other threads:[~2008-02-12 18:14 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-02-11  7:43 Linux 2.6.22.18 Greg Kroah-Hartman
2008-02-11  7:43 ` Greg Kroah-Hartman
2008-02-11 11:31   ` Matthew Keenan
2008-02-11 15:45     ` Greg KH
2008-02-12 17:48       ` Florian Weimer
2008-02-12 17:50         ` Greg KH
2008-02-11 16:32     ` Linus Torvalds

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).