We (the -stable team) are announcing the release of the 2.6.16.16
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.15 and 2.6.16.16, 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/locks.c | 21 ++++++++++++---------
2 files changed, 13 insertions(+), 10 deletions(-)
Summary of changes from v2.6.16.15 to v2.6.16.16
================================================
Chris Wright:
Linux 2.6.16.16
Trond Myklebust:
fs/locks.c: Fix lease_init (CVE-2006-1860)
diff --git a/Makefile b/Makefile
index cdd3ce7..b93f75f 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 16
-EXTRAVERSION = .15
+EXTRAVERSION = .16
NAME=Sliding Snow Leopard
# *DOCUMENTATION*
diff --git a/fs/locks.c b/fs/locks.c
index e75ac39..aa7f660 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -432,15 +432,14 @@ static struct lock_manager_operations le
*/
static int lease_init(struct file *filp, int type, struct file_lock *fl)
{
+ if (assign_type(fl, type) != 0)
+ return -EINVAL;
+
fl->fl_owner = current->files;
fl->fl_pid = current->tgid;
fl->fl_file = filp;
fl->fl_flags = FL_LEASE;
- if (assign_type(fl, type) != 0) {
- locks_free_lock(fl);
- return -EINVAL;
- }
fl->fl_start = 0;
fl->fl_end = OFFSET_MAX;
fl->fl_ops = NULL;
@@ -452,16 +451,19 @@ static int lease_init(struct file *filp,
static int lease_alloc(struct file *filp, int type, struct file_lock **flp)
{
struct file_lock *fl = locks_alloc_lock();
- int error;
+ int error = -ENOMEM;
if (fl == NULL)
- return -ENOMEM;
+ goto out;
error = lease_init(filp, type, fl);
- if (error)
- return error;
+ if (error) {
+ locks_free_lock(fl);
+ fl = NULL;
+ }
+out:
*flp = fl;
- return 0;
+ return error;
}
/* Check if two locks overlap each other.
@@ -1337,6 +1339,7 @@ static int __setlease(struct file *filp,
goto out;
if (my_before != NULL) {
+ *flp = *my_before;
error = lease->fl_lmops->fl_change(my_before, arg);
goto out;
}
Hello Chris,
Thursday, May 11, 2006, 4:25:47 AM, you wrote:
> Trond Myklebust:
> fs/locks.c: Fix lease_init (CVE-2006-1860)
I want to say that I like the quick stable cycle. People like to see
fixes. Big thanks!
However...
I must say that usually I know if I need the the update,
eg. I do not care for SCTP that much so I could skip that update.
But this one looks important, something that every kernel build
has in its code path, however I am unable to say if I need it badly
or maybe not.
The url: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1860
says nothing about it.
Could we have a word or two under each patchlet that would qualify them
somehow?
Like:
"Important, not required for all, apply if using SCTP"
"Important, required for all, may *do bad things*, apply ASAP"
"Critical, required for all, surely will *do bad things*, apply ASAP"
Not only distro kernel developers/maintainers use these, so I think
it would be nice.
Best Regards,
Maciej
On 11/05/06, Maciej Soltysiak <[email protected]> wrote:
> But this one looks important, something that every kernel build
> has in its code path, however I am unable to say if I need it badly
> or maybe not.
>
> The url: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1860
> says nothing about it.
>
> Could we have a word or two under each patchlet that would qualify them
> somehow?
> Like:
> "Important, not required for all, apply if using SCTP"
> "Important, required for all, may *do bad things*, apply ASAP"
> "Critical, required for all, surely will *do bad things*, apply ASAP"
This is exactly my thoughts. I read the changelog:
http://kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.16.16
and it does look important, but I am not sure either if I need to apply.
Good suggestion, Maciej!
Nick
On Thu, 11 May 2006, Maciej Soltysiak wrote:
> Hello Chris,
>
> Thursday, May 11, 2006, 4:25:47 AM, you wrote:
> > Trond Myklebust:
> > fs/locks.c: Fix lease_init (CVE-2006-1860)
> I want to say that I like the quick stable cycle. People like to see
> fixes. Big thanks!
>
> However...
> I must say that usually I know if I need the the update,
> eg. I do not care for SCTP that much so I could skip that update.
>
> But this one looks important, something that every kernel build
> has in its code path, however I am unable to say if I need it badly
> or maybe not.
It looks from the commit that it is a user-triggerable lockup and memory
leak. Perhaps the posting of the patch should include the comments?
-Daniel
*This .sig left intentionally blank*
* Maciej Soltysiak ([email protected]) wrote:
> But this one looks important, something that every kernel build
> has in its code path, however I am unable to say if I need it badly
> or maybe not.
The patch fixes a possible user-triggerable system lockup or memory leak.
In both cases it's a local DoS.
BTW, the CVE folks have decided to track this as two separate issues:
CVE-2006-1860 - the system lockup
CVE-2006-1859 - the memory leak
> Could we have a word or two under each patchlet that would qualify them
> somehow?
> Like:
> "Important, not required for all, apply if using SCTP"
> "Important, required for all, may *do bad things*, apply ASAP"
> "Critical, required for all, surely will *do bad things*, apply ASAP"
Assigning any official severity is a bit of a slippery slope, but
making sure it's clear what type of issue (i.e. local DoS in this case)
is very reasonable.
thanks,
-chris
Error:
kernel: hdi: drive_cmd: status=0xd0 { Busy }
kernel: ide: failed opcode was: 0xea
BUG: soft lockup detected on CPU#0!
the odd thing is the system experiences a hard lockup,
so it is not a false positive. I am working on a
trace, but it is hard to get.
My supervisor has asked me to help research this
problem. We are using multiple ata cards in our backup
machine. We have a Promiss sata 300tx4, and three ATA
cards (3 SIG UltraATA 133 PCI) or (3 promise ultra
100tx2). We are experiencing hard lockups. The system
resides on a scsi drive connected to the on board
controler Adaptec AIC-7899P (Tyan S2462
motherboard)the error is repeated for all drives
connected to the promis cards, and the error continues
until a lock up is eventualy reached.
Also, its in dma mode, not pio.
PREEMPT_NONE is already set, so its not the preemption
model
possibly related posts
http://www.ussg.iu.edu/hypermail/linux/kernel/0309.1/0444.html
http://groups.google.com/group/linux.kernel/browse_thread/thread/450966ffa3043609/59e6a2350b7690bf?lnk=st&q=kernel%3A+ide%3A+failed+opcode+was%3A+0xea%22+BUG%3A+soft+lockup+detected+on+CPU%230!%22&rnum=1&hl=en#59e6a2350b7690bf
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
I noticed another post the other day, and contacted
the indavidual who posted it. note his message below.
Hi Winn,
Latest news i had was a *hint* from Andrew Morton
telling me to try with kernel 2.6.17-rc3 and report if
the problem was gone or not. I've had no
time to give it a try yet.Your problem seems similar
to mine, a few person argued that the message
was bogus and that no harm was done but i guess they
did not read carefully the post since the consequences
are pretty bad.
Let me know if you manage to try with the latest rc of
the 2.6.17 kernel and if things are better.
ref:
http://groups.google.com/group/linux.kernel/browse_thread/thread/450966ffa3043609/59e6a2350b7690bf?lnk=st&q=kernel%3A+ide%3A+failed+opcode+was%3A+0xea%22+BUG%3A+soft+lockup+detected+on+CPU%230!%22&rnum=1&hl=en#59e6a2350b7690bf
--- Winn Johnston <[email protected]> wrote:
> Error:
>
> kernel: hdi: drive_cmd: status=0xd0 { Busy }
> kernel: ide: failed opcode was: 0xea
> BUG: soft lockup detected on CPU#0!
>
> the odd thing is the system experiences a hard
> lockup,
> so it is not a false positive. I am working on a
> trace, but it is hard to get.
>
> My supervisor has asked me to help research this
> problem. We are using multiple ata cards in our
> backup
> machine. We have a Promiss sata 300tx4, and three
> ATA
> cards (3 SIG UltraATA 133 PCI) or (3 promise ultra
> 100tx2). We are experiencing hard lockups. The
> system
> resides on a scsi drive connected to the on board
> controler Adaptec AIC-7899P (Tyan S2462
> motherboard)the error is repeated for all drives
> connected to the promis cards, and the error
> continues
> until a lock up is eventualy reached.
>
> Also, its in dma mode, not pio.
> PREEMPT_NONE is already set, so its not the
> preemption
> model
>
> possibly related posts
>
http://www.ussg.iu.edu/hypermail/linux/kernel/0309.1/0444.html
>
>
http://groups.google.com/group/linux.kernel/browse_thread/thread/450966ffa3043609/59e6a2350b7690bf?lnk=st&q=kernel%3A+ide%3A+failed+opcode+was%3A+0xea%22+BUG%3A+soft+lockup+detected+on+CPU%230!%22&rnum=1&hl=en#59e6a2350b7690bf
>
>
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam
> protection around
> http://mail.yahoo.com
> -
> To unsubscribe from this list: send the line
> "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at
> http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Hi Chris,
first of all: Thanks for the good work!
On Thursday, 11. May 2006 19:33, Chris Wright wrote:
> Assigning any official severity is a bit of a slippery slope, but
> making sure it's clear what type of issue (i.e. local DoS in this case)
> is very reasonable.
Yes, I agree.
I would like to know:
- local or remote exploitable
- if a DoS: hang, only service failure, major slowdown
- privilege escalation possiible and how far (valid user, root, kernel-level)
- required privileges (root or user)
That would help risk management a lot :-)
If you have a lot of time: Affected software components, but these can
be taken from the patches/commit info or CVE.
Thanks & Regards
Ingo Oeser
On Sat, May 13, 2006 at 05:35:19PM +0200, Ingo Oeser wrote:
> Hi Chris,
>
> first of all: Thanks for the good work!
>
> On Thursday, 11. May 2006 19:33, Chris Wright wrote:
> > Assigning any official severity is a bit of a slippery slope, but
> > making sure it's clear what type of issue (i.e. local DoS in this case)
> > is very reasonable.
>
> Yes, I agree.
>
> I would like to know:
> - local or remote exploitable
> - if a DoS: hang, only service failure, major slowdown
> - privilege escalation possiible and how far (valid user, root, kernel-level)
> - required privileges (root or user)
>
> That would help risk management a lot :-)
>
> If you have a lot of time: Affected software components, but these can
> be taken from the patches/commit info or CVE.
The CVE should be enough for easily getting all information you
requested.
Information whether it's a DoS or a root exploit is helpful, but any
qualified person doing risk management will anyways lookup the CVE.
> Thanks & Regards
>
> Ingo Oeser
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On 13/05/06, Adrian Bunk <[email protected]> wrote:
> The CVE should be enough for easily getting all information you
> requested.
>
> Information whether it's a DoS or a root exploit is helpful, but any
> qualified person doing risk management will anyways lookup the CVE.
Well, yes, but some people do *actually* use the latest kernel at home
and not in labs (et al), and as Maciej asked, we are not sure whether
the (whatever) latest patch is needed or not on whatever our current
config is the way the latest stable fixes are announced.
" [PATCH] fs/locks.c: Fix lease_init (CVE-2006-1860)
It is insane to be giving lease_init() the task of freeing the lock it is
supposed to initialise, given that the lock is not guaranteed to be
allocated on the stack. This causes lockups in fcntl_setlease().
Problem diagnosed by Daniel Hokka Zakrisson <[email protected]>
Also fix a slab leak in __setlease() due to an uninitialised return value.
Problem diagnosed by Björn Steinbrink.
"
OK, great. But what does it mean?
It would be nice to have a short explanation of what the fix is for in
real world terms.
Nick
On Sat, May 13, 2006 at 06:29:25PM +0100, Nick Warne wrote:
> On 13/05/06, Adrian Bunk <[email protected]> wrote:
> >The CVE should be enough for easily getting all information you
> >requested.
> >
> >Information whether it's a DoS or a root exploit is helpful, but any
> >qualified person doing risk management will anyways lookup the CVE.
>
> Well, yes, but some people do *actually* use the latest kernel at home
> and not in labs (et al), and as Maciej asked, we are not sure whether
> the (whatever) latest patch is needed or not on whatever our current
> config is the way the latest stable fixes are announced.
>
> " [PATCH] fs/locks.c: Fix lease_init (CVE-2006-1860)
>
> It is insane to be giving lease_init() the task of freeing the lock it is
> supposed to initialise, given that the lock is not guaranteed to be
> allocated on the stack. This causes lockups in fcntl_setlease().
> Problem diagnosed by Daniel Hokka Zakrisson <[email protected]>
>
> Also fix a slab leak in __setlease() due to an uninitialised return
> value.
> Problem diagnosed by Bj????rn Steinbrink.
> "
>
> OK, great. But what does it mean?
>
> It would be nice to have a short explanation of what the fix is for in
> real world terms.
To be fair, the extra work of writing out a detailed exploit, complete
with example code, for every security update, would just take way too
long. If you look for where this patch was discussed on lkml, you will
see a full description of the problem, and how to hit it.
thanks,
greg k-h
Hi Greg,
On Sat, May 13, 2006 at 08:59:37PM -0700, Greg KH wrote:
> On Sat, May 13, 2006 at 06:29:25PM +0100, Nick Warne wrote:
> > On 13/05/06, Adrian Bunk <[email protected]> wrote:
> > >The CVE should be enough for easily getting all information you
> > >requested.
> > >
> > >Information whether it's a DoS or a root exploit is helpful, but any
> > >qualified person doing risk management will anyways lookup the CVE.
> >
> > Well, yes, but some people do *actually* use the latest kernel at home
> > and not in labs (et al), and as Maciej asked, we are not sure whether
> > the (whatever) latest patch is needed or not on whatever our current
> > config is the way the latest stable fixes are announced.
> >
> > " [PATCH] fs/locks.c: Fix lease_init (CVE-2006-1860)
> >
> > It is insane to be giving lease_init() the task of freeing the lock it is
> > supposed to initialise, given that the lock is not guaranteed to be
> > allocated on the stack. This causes lockups in fcntl_setlease().
> > Problem diagnosed by Daniel Hokka Zakrisson <[email protected]>
> >
> > Also fix a slab leak in __setlease() due to an uninitialised return
> > value.
> > Problem diagnosed by Bj????rn Steinbrink.
> > "
> >
> > OK, great. But what does it mean?
> >
> > It would be nice to have a short explanation of what the fix is for in
> > real world terms.
>
> To be fair, the extra work of writing out a detailed exploit, complete
> with example code, for every security update, would just take way too
> long. If you look for where this patch was discussed on lkml, you will
> see a full description of the problem, and how to hit it.
I second this. I try to write detailed changes or at least to compact
the original explanations for patches that go into 2.4 hotfixes, and
sometimes I wonder if I don't do too much. It takes nearly 1/3 of the
time to get the patches in and compile the kernel, and 2/3 of the time
to write things that I sometimes think very few people will read. I
think that if i still do it, it's because I release far less often than
you and Chris do. Otherwise I would have given up.
One compromise might be to post the full changelog in the announcement
in addition to the shortlog. But I agree that security fixes are rarely
well documented by their authors, and CVE descriptions are sometimes
rather obscure :-(
> thanks,
>
> greg k-h
Regards,
Willy
Hello Greg,
Sunday, May 14, 2006, 5:59:37 AM, you wrote:
> To be fair, the extra work of writing out a detailed exploit, complete
> with example code, for every security update, would just take way too
> long.
Well, I think what we meant is just a one-liner hint from a wise developer
suggesting some action, meaning something like: "This one I recommend to all"
or "Use this if you use SCTP" or "X can do nasty things, you should upgrade
if you are using it". If the patch title is "Fix a buffer overflow in foo"
everybody knows what to do, but when it says "Fix foo so that baz stays barred"
an additional hint would be nice, because it's ambiguous for someone
just tracking stable releases and not being knowledgible enough to decide
whether baz is a function or system call that they are using.
I was not suggesting full detailed reports, I know the developers have better
things to do, just some hints :-)
--
Best regards,
Maciej
On Sun, May 14, 2006 at 09:46:39AM +0200, Maciej Soltysiak wrote:
> Hello Greg,
>
> Sunday, May 14, 2006, 5:59:37 AM, you wrote:
> > To be fair, the extra work of writing out a detailed exploit, complete
> > with example code, for every security update, would just take way too
> > long.
> Well, I think what we meant is just a one-liner hint from a wise developer
> suggesting some action, meaning something like: "This one I recommend to all"
> or "Use this if you use SCTP" or "X can do nasty things, you should upgrade
> if you are using it". If the patch title is "Fix a buffer overflow in foo"
> everybody knows what to do, but when it says "Fix foo so that baz stays barred"
> an additional hint would be nice, because it's ambiguous for someone
> just tracking stable releases and not being knowledgible enough to decide
> whether baz is a function or system call that they are using.
>
> I was not suggesting full detailed reports, I know the developers have better
> things to do, just some hints :-)
If you read the full patch description, or the full changelog, you will
almost always get those hints. The changelog is always availble on
kernel.org next to the kernel patch/source tree.
thanks,
greg k-h
* Willy Tarreau ([email protected]) wrote:
> One compromise might be to post the full changelog in the announcement
> in addition to the shortlog. But I agree that security fixes are rarely
> well documented by their authors, and CVE descriptions are sometimes
> rather obscure :-(
My preference is to leave things concise. If one has a question, the
CVE and the full Changelog are pretty easy to obtain and read.
thanks,
-chris