We (the -stable team) are announcing the release of the 2.6.16.14
kernel.
The diffstat and short summary of the fixes are below.
I'll also be replying to this message with a copy of the patch between
2.6.16.13 and 2.6.16.14, as it is small enough to do so.
The updated 2.6.16.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git
and can be browsed at the normal kernel.org git web browser:
http://www.kernel.org/git/
thanks,
-chris
--------
Makefile | 2 +-
fs/smbfs/dir.c | 5 +++++
2 files changed, 6 insertions(+), 1 deletion(-)
Summary of changes from v2.6.16.13 to v2.6.16.14
================================================
Chris Wright:
Linux 2.6.16.14
Olaf Kirch:
smbfs chroot issue (CVE-2006-1864)
diff --git a/Makefile b/Makefile
index d4cc824..3c03fb9 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 16
-EXTRAVERSION = .13
+EXTRAVERSION = .14
NAME=Sliding Snow Leopard
# *DOCUMENTATION*
diff --git a/fs/smbfs/dir.c b/fs/smbfs/dir.c
index 0424d06..45862ec 100644
--- a/fs/smbfs/dir.c
+++ b/fs/smbfs/dir.c
@@ -434,6 +434,11 @@ smb_lookup(struct inode *dir, struct den
if (dentry->d_name.len > SMB_MAXNAMELEN)
goto out;
+ /* Do not allow lookup of names with backslashes in */
+ error = -EINVAL;
+ if (memchr(dentry->d_name.name, '\\', dentry->d_name.len))
+ goto out;
+
lock_kernel();
error = smb_proc_getattr(dentry, &finfo);
#ifdef SMBFS_PARANOIA
Hi.
On Friday 05 May 2006 10:35, Chris Wright wrote:
> We (the -stable team) are announcing the release of the 2.6.16.14
> kernel.
Is this supposed to be some sort of subtle pressure on Linus to open 2.7? :>
Regards,
Nigel
On 5/4/06, Nigel Cunningham <[email protected]> wrote:
> Is this supposed to be some sort of subtle pressure on Linus to open 2.7? :>
I think the "poor suckers" maintaining -stable have more noble agendas.
* Nigel Cunningham ([email protected]) wrote:
> Is this supposed to be some sort of subtle pressure on Linus to open 2.7? :>
He does every couple months and leaves it open for a few weeks.
Then, just to keep us guessing, he releases it with a 2.6 name ;-)
Actually, I think the system is working quite well. We've got a quick
route for getting bug fixes and security fixes to users, and a shorter
devel cycle helping distro folks get more regular drops from upstream.
This particular patch applies all the way back to the beginning of git
time (over a year ago), and I'm sure earlier. So it's hard to conclude
it's a byproduct of the release cycles.
thanks,
-chris
Hi.
On Friday 05 May 2006 12:33, Chris Wright wrote:
> * Nigel Cunningham ([email protected]) wrote:
> > Is this supposed to be some sort of subtle pressure on Linus to open 2.7?
> > :>
>
> He does every couple months and leaves it open for a few weeks.
> Then, just to keep us guessing, he releases it with a 2.6 name ;-)
>
> Actually, I think the system is working quite well. We've got a quick
> route for getting bug fixes and security fixes to users, and a shorter
> devel cycle helping distro folks get more regular drops from upstream.
> This particular patch applies all the way back to the beginning of git
> time (over a year ago), and I'm sure earlier. So it's hard to conclude
> it's a byproduct of the release cycles.
:) Tongue was firmly in cheek. I guess I should have said more initially. It
wasn't so much the patch, as the speed with which they're coming. It makes me
(at least) feel like the stable series is unstable. Couldn't you store them
up for a day or two at a time (unless of course they really are that
important that they require a quicker cycle).
Regards,
Nigel
On 5/4/06, Nigel Cunningham <[email protected]> wrote:
> :) Tongue was firmly in cheek. I guess I should have said more initially. It
> wasn't so much the patch, as the speed with which they're coming. It makes me
> (at least) feel like the stable series is unstable. Couldn't you store them
> up for a day or two at a time (unless of course they really are that
> important that they require a quicker cycle).
I'm sure that they would be stored till Tuesdays if the linux kernel
had a PR department...
* Nigel Cunningham ([email protected]) wrote:
> :) Tongue was firmly in cheek. I guess I should have said more initially. It
I figured it was a bit tongue in cheek ;-)
> wasn't so much the patch, as the speed with which they're coming. It makes me
> (at least) feel like the stable series is unstable. Couldn't you store them
> up for a day or two at a time (unless of course they really are that
> important that they require a quicker cycle).
Typically we do. The security patches tend to go out straight away,
unless they are very low risk, at which point they are batched with the
others. But once we know of a user triggerable security hole, it's
best to release rather than sit on it.
thanks,
-chris
On Thu, May 04, 2006 at 08:25:54PM -0700, Chris Wright wrote:
> Typically we do. The security patches tend to go out straight away,
> unless they are very low risk, at which point they are batched with the
> others. But once we know of a user triggerable security hole, it's
> best to release rather than sit on it.
I was wondering, will there be another/more stable .15 releases?
--
"To the extent that we overreact, we proffer the terrorists the
greatest tribute."
- High Court Judge Michael Kirby
On Thursday 04 May 2006 23:18, Ioan Ionita wrote:
> On 5/4/06, Nigel Cunningham <[email protected]> wrote:
> > :) Tongue was firmly in cheek. I guess I should have said more initially.
> > : It
> >
> > wasn't so much the patch, as the speed with which they're coming. It
> > makes me (at least) feel like the stable series is unstable. Couldn't you
> > store them up for a day or two at a time (unless of course they really
> > are that important that they require a quicker cycle).
>
> I'm sure that they would be stored till Tuesdays if the linux kernel
> had a PR department...
Thank $DIETY that Linux isn't an end-user product, then. (Then again, even
FOSS end-user products have been known to tell their PR people to stuff
it...)
--
Patrick McFarland || http://www.AdAstraPerAspera.com
"Computer games don't affect kids; I mean if Pac-Man affected us as kids,
we'd all be running around in darkened rooms, munching magic pills and
listening to repetitive electronic music." -- Kristian Wilson, Nintendo,
Inc, 1989
Hi Nigel,
On Fri, May 05, 2006 at 01:03:31PM +1000, Nigel Cunningham wrote:
> Hi.
>
> On Friday 05 May 2006 12:33, Chris Wright wrote:
> > * Nigel Cunningham ([email protected]) wrote:
> > > Is this supposed to be some sort of subtle pressure on Linus to open 2.7?
> > > :>
> >
> > He does every couple months and leaves it open for a few weeks.
> > Then, just to keep us guessing, he releases it with a 2.6 name ;-)
> >
> > Actually, I think the system is working quite well. We've got a quick
> > route for getting bug fixes and security fixes to users, and a shorter
> > devel cycle helping distro folks get more regular drops from upstream.
> > This particular patch applies all the way back to the beginning of git
> > time (over a year ago), and I'm sure earlier. So it's hard to conclude
> > it's a byproduct of the release cycles.
>
> :) Tongue was firmly in cheek. I guess I should have said more initially. It
> wasn't so much the patch, as the speed with which they're coming. It makes me
> (at least) feel like the stable series is unstable. Couldn't you store them
> up for a day or two at a time (unless of course they really are that
> important that they require a quicker cycle).
I don't agree with your analysis at all. Quite the opposite in fact. I'm
amazed that Chris & Greg manage to update so often. Right now, you can be
confident that there's always an *official* kernel version which fixes a
few days-old vulnerability. I'd like to be that fast to provide 2.4 hotfixes
(I still have one fix pending).
The enormous advantage of releasing lots of small updates is that people
just have to choose when they want to update. If you're not affected by
the SMB vulnerability, don't upgrade. That's that simple. It makes it
much easier to class bug reports (eg: the last one on speedstep which
"appeared" in 2.6.16.13 and not 2.6.16.12 while no such code has changed).
Sometimes, a config option will have changed on the user side, or a gcc
update will have been performed which might explain a new bug which we
can be certain does not come from the source.
What might be interesting with this release cycle would be to work on
hot-patching. There has already been such things in the past with modules
which patched some functions. It would avoid a full compile and a reboot
in some circumstances.
That said, kudos to Chris and Greg for their excellent work ! Please
don't change.
> Regards,
>
> Nigel
Regards,
Willy
Hi Willy.
On Friday 05 May 2006 14:50, Willy Tarreau wrote:
> Hi Nigel,
>
> On Fri, May 05, 2006 at 01:03:31PM +1000, Nigel Cunningham wrote:
> > Hi.
> >
> > On Friday 05 May 2006 12:33, Chris Wright wrote:
> > > * Nigel Cunningham ([email protected]) wrote:
> > > > Is this supposed to be some sort of subtle pressure on Linus to open
> > > > 2.7?
> > >
> > > He does every couple months and leaves it open for a few weeks.
> > > Then, just to keep us guessing, he releases it with a 2.6 name ;-)
> > >
> > > Actually, I think the system is working quite well. We've got a quick
> > > route for getting bug fixes and security fixes to users, and a shorter
> > > devel cycle helping distro folks get more regular drops from upstream.
> > > This particular patch applies all the way back to the beginning of git
> > > time (over a year ago), and I'm sure earlier. So it's hard to conclude
> > > it's a byproduct of the release cycles.
> > >
> > :) Tongue was firmly in cheek. I guess I should have said more initially.
> > : It
> >
> > wasn't so much the patch, as the speed with which they're coming. It
> > makes me (at least) feel like the stable series is unstable. Couldn't you
> > store them up for a day or two at a time (unless of course they really
> > are that important that they require a quicker cycle).
>
> I don't agree with your analysis at all. Quite the opposite in fact. I'm
> amazed that Chris & Greg manage to update so often. Right now, you can be
> confident that there's always an *official* kernel version which fixes a
> few days-old vulnerability. I'd like to be that fast to provide 2.4
> hotfixes (I still have one fix pending).
>
> The enormous advantage of releasing lots of small updates is that people
> just have to choose when they want to update. If you're not affected by
> the SMB vulnerability, don't upgrade. That's that simple. It makes it
> much easier to class bug reports (eg: the last one on speedstep which
> "appeared" in 2.6.16.13 and not 2.6.16.12 while no such code has changed).
> Sometimes, a config option will have changed on the user side, or a gcc
> update will have been performed which might explain a new bug which we
> can be certain does not come from the source.
>
> What might be interesting with this release cycle would be to work on
> hot-patching. There has already been such things in the past with modules
> which patched some functions. It would avoid a full compile and a reboot
> in some circumstances.
>
> That said, kudos to Chris and Greg for their excellent work ! Please
> don't change.
>
> > Regards,
> >
> > Nigel
>
> Regards,
> Willy
Thanks for your email. I can certainly see the validity of the points you
make - I guess it just goes to prove that there is often more than one way of
looking at things :)
I didn't mention it previously - I guess because it was subconscious - but I'm
looking at things from the point of view of someone maintaining an
out-of-tree patch. With almost all of these revisions, my patch continues to
apply cleanly, but I still get people asking "Is the patch for 2.6.16.9" safe
to apply against "2.6.16.9+x"? I simply don't have the time to continually
test and check, but I end up feeling like there's a new 2.6.x release
everyday that I just have to keep up with, because that's what the stable
users want. Maybe it just proves that I should hurry up and get the git tree
finished so I get try to get Suspend2 merged :)
Regards,
Nigel
On Fri, May 05, 2006 at 01:33:25PM +1000, CaT wrote:
> On Thu, May 04, 2006 at 08:25:54PM -0700, Chris Wright wrote:
> > Typically we do. The security patches tend to go out straight away,
> > unless they are very low risk, at which point they are batched with the
> > others. But once we know of a user triggerable security hole, it's
> > best to release rather than sit on it.
>
> I was wondering, will there be another/more stable .15 releases?
I don't think that Chris or I will be doing any, as we don't have any
pending patches against that tree that people have sent us. If you, or
someone else wants to take over the .15 tree, feel free :)
good luck,
greg k-h
On Fri, May 05, 2006 at 03:02:47PM +1000, Nigel Cunningham wrote:
> Hi Willy.
(snip)
>
> I didn't mention it previously - I guess because it was subconscious - but I'm
> looking at things from the point of view of someone maintaining an
> out-of-tree patch. With almost all of these revisions, my patch continues to
> apply cleanly, but I still get people asking "Is the patch for 2.6.16.9" safe
> to apply against "2.6.16.9+x"? I simply don't have the time to continually
> test and check, but I end up feeling like there's a new 2.6.x release
> everyday that I just have to keep up with, because that's what the stable
> users want. Maybe it just proves that I should hurry up and get the git tree
> finished so I get try to get Suspend2 merged :)
Oh yes, I understand your problem, I went through that for several years with
2.4. Another advantage of many small updates is that the risk of conflict is
minor, and your users might often be able to apply the official patch *after*
your patch, which is very convenient.
Maybe you should just run a cron script to patch your kernels everytime a
new fix goes out, so that you'll at least be able to reply to your users
whether it's supposed to work or not.
> Regards,
>
> Nigel
Regards,
Willy
On Friday 05 May 2006 03:33, Chris Wright wrote:
> * Nigel Cunningham ([email protected]) wrote:
> > Is this supposed to be some sort of subtle pressure on Linus to open 2.7?
> > :>
>
> He does every couple months and leaves it open for a few weeks.
> Then, just to keep us guessing, he releases it with a 2.6 name ;-)
>
> Actually, I think the system is working quite well. We've got a quick
> route for getting bug fixes and security fixes to users, and a shorter
> devel cycle helping distro folks get more regular drops from upstream.
I think it's working extremely well. When it comes to security fixes, I want
them as soon as possible. There's no sense batching them.
The only thing to be careful of is that -stable fixes (or complete reworks)
get merged with mainline, so the trees don't go out of sync. So far this
seems to have been OK.
--
Cheers,
Alistair.
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
On 5/4/06, Chris Wright <[email protected]> wrote:
> We (the -stable team) are announcing the release of the 2.6.16.14
> kernel.
>
> The diffstat and short summary of the fixes are below.
>
> I'll also be replying to this message with a copy of the patch between
> 2.6.16.13 and 2.6.16.14, as it is small enough to do so.
>
> The updated 2.6.16.y git tree can be found at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git
> and can be browsed at the normal kernel.org git web browser:
> http://www.kernel.org/git/
That still shows the /stable/linux-2.6.16-y.git tree at 2.6.16.13. FYI.
josh
* Josh Boyer ([email protected]) wrote:
> That still shows the /stable/linux-2.6.16-y.git tree at 2.6.16.13. FYI.
Yeah, minor technical glitch. Part of the tree was unwritable so my
updates needed manual intervention. Should be all fixed now.
thanks,
-chris
Alistair John Strachan wrote:
> On Friday 05 May 2006 03:33, Chris Wright wrote:
>> * Nigel Cunningham ([email protected]) wrote:
>>> Is this supposed to be some sort of subtle pressure on Linus to open 2.7?
>>> :>
>> He does every couple months and leaves it open for a few weeks.
>> Then, just to keep us guessing, he releases it with a 2.6 name ;-)
>>
>> Actually, I think the system is working quite well. We've got a quick
>> route for getting bug fixes and security fixes to users, and a shorter
>> devel cycle helping distro folks get more regular drops from upstream.
>
> I think it's working extremely well. When it comes to security fixes, I want
> them as soon as possible. There's no sense batching them.
>
> The only thing to be careful of is that -stable fixes (or complete reworks)
> get merged with mainline, so the trees don't go out of sync. So far this
> seems to have been OK.
>
As I recall these patches may or may not go into mainline. The next full
release may address the problem in a whole new way.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
* Bill Davidsen ([email protected]) wrote:
> Alistair John Strachan wrote:
> >The only thing to be careful of is that -stable fixes (or complete
> >reworks) get merged with mainline, so the trees don't go out of sync. So
> >far this seems to have been OK.
> >
> As I recall these patches may or may not go into mainline. The next full
> release may address the problem in a whole new way.
As a general rule, we do our best to keep in sync. Typically they go
to mainline first. A few security patches may bypass that and go in
parallel. And, of course, anything that's since been redone in mainline
to the point that the patch is not relevant will only live in -stable.
thanks,
-chris