Linux 2.6.17.5
Greg KH
I'll also be replying to this message with a copy of the patch between
2.6.17.4 and 2.6.17.5, as it is small enough to do so.
The updated 2.6.17.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.17.y.git
and can be browsed at the normal kernel.org git web browser:
www.kernel.org/git/
thanks,
greg k-h
--------
Makefile | 2 +-
fs/proc/base.c | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
Summary of changes from v2.6.17.4 to v2.6.17.5
==============================================
Greg Kroah-Hartman:
Linux 2.6.17.5
Linus Torvalds:
Fix nasty /proc vulnerability (CVE-2006-3626)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Greg KH
index abcf2d7..cb8b93c 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 17
-EXTRAVERSION = .4
+EXTRAVERSION = .5
NAME=Crazed Snow-Weasel
# *DOCUMENTATION*
diff --git a/fs/proc/base.c b/fs/proc/base.c
index 6cc77dc..5a8b89a 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -1404,6 +1404,7 @@ static int pid_revalidate(struct dentry
} else {
inode->i_uid = 0;
inode->i_gid = 0;
+ inode->i_mode = 0;
}
security_task_to_inode(task, inode);
return 1;
Greg KH
> We (the -stable team) are announcing the release of the 2.6.17.5 kernel.
Oops, please note that we now have some reports that this patch breaks
some versions of HAL. So if you're relying on HAL, you might not want
to use this fix just yet (please evaluate the risks of doing this on
your own.)
Note that HAL usually does not run on servers, so this should be safe
there. We'll try to provide a better fix soon...
Sorry about this.
greg k-h
Greg KH
> On Fri, Jul 14, 2006 at 08:00:47PM -0700, Greg KH wrote:
> > We (the -stable team) are announcing the release of the 2.6.17.5 kernel.
>
> Oops, please note that we now have some reports that this patch breaks
> some versions of HAL. So if you're relying on HAL, you might not want
> to use this fix just yet (please evaluate the risks of doing this on
> your own.)
Hm, HAL 0.5.7 seems to work fine for me. Anyone else seeing any
problems with this version? Older versions?
thanks,
Linus Torvalds
On Fri, 14 Jul 2006, Greg KH wrote:
>
> I'll also be replying to this message with a copy of the patch between
> 2.6.17.4 and 2.6.17.5, as it is small enough to do so.
I did a slight modification of the patch I committed initially, in the
face of the report from Marcel that the initial sledge-hammer approach
broke his hald setup.
See commit 9ee8ab9fbf21e6b87ad227cd46c0a4be41ab749b: "Relax /proc fix a
bit", which should still fix the bug (can somebody verify? I'm 100% sure,
but still..), but is pretty much guaranteed to not have any secondary side
effects.
It still leaves the whole issue of whether /proc should honor chmod AT ALL
open, and I'd love to close that one, but from a "minimal fix" standpoint,
I think it's a reasonable (and simple) patch.
Marcel, can you check current git?
Linus
Bastian Blank
> It still leaves the whole issue of whether /proc should honor chmod AT ALL
> open,
Hmm, can you explain why notify_change (fs/attr.c) don't bail out if the
inode lacks the setattr function and instead just sets the new
permissions?
I really think this is the wrong way and inodes which want this default
behaviour should explicitely define it.
Bastian
--
Each kiss is as the first.
-- Miramanee, Kirk's wife, "The Paradise Syndrome",
stardate 4842.6
Daniel Drake
Linus Torvalds wrote:
> I did a slight modification of the patch I committed initially, in the
> face of the report from Marcel that the initial sledge-hammer approach
> broke his hald setup.
>
> See commit 9ee8ab9fbf21e6b87ad227cd46c0a4be41ab749b: "Relax /proc fix a
> bit", which should still fix the bug (can somebody verify? I'm 100% sure,
> but still..), but is pretty much guaranteed to not have any secondary side
> effects.
>
> It still leaves the whole issue of whether /proc should honor chmod AT ALL
> open, and I'd love to close that one, but from a "minimal fix" standpoint,
> I think it's a reasonable (and simple) patch.
>
> Marcel, can you check current git?
I can confirm that the new fix prevents the exploit from working, with
no immediately visible side effects.
Thanks,
Daniel
Von Wolher
> Hi Linus,
>
> Linus Torvalds wrote:
>
>> I did a slight modification of the patch I committed initially, in the
>> face of the report from Marcel that the initial sledge-hammer approach
>> broke his hald setup.
>>
>> See commit 9ee8ab9fbf21e6b87ad227cd46c0a4be41ab749b: "Relax /proc fix
>> a bit", which should still fix the bug (can somebody verify? I'm 100%
>> sure, but still..), but is pretty much guaranteed to not have any
>> secondary side effects.
>>
>> It still leaves the whole issue of whether /proc should honor chmod AT
>> ALL open, and I'd love to close that one, but from a "minimal fix"
>> standpoint, I think it's a reasonable (and simple) patch.
>>
>> Marcel, can you check current git?
>
>
> I can confirm that the new fix prevents the exploit from working, with
> no immediately visible side effects.
>
> Thanks,
> Daniel
>
Can some one release a 2.6.17.6 ? I think many people are waiting at
their keyboard to get their systems protected.
Appreciate the quick response !
Thanks,
Mark
Greg KH
> Daniel Drake wrote:
> > Hi Linus,
> >
> > Linus Torvalds wrote:
> >
> >> I did a slight modification of the patch I committed initially, in the
> >> face of the report from Marcel that the initial sledge-hammer approach
> >> broke his hald setup.
> >>
> >> See commit 9ee8ab9fbf21e6b87ad227cd46c0a4be41ab749b: "Relax /proc fix
> >> a bit", which should still fix the bug (can somebody verify? I'm 100%
> >> sure, but still..), but is pretty much guaranteed to not have any
> >> secondary side effects.
> >>
> >> It still leaves the whole issue of whether /proc should honor chmod AT
> >> ALL open, and I'd love to close that one, but from a "minimal fix"
> >> standpoint, I think it's a reasonable (and simple) patch.
> >>
> >> Marcel, can you check current git?
> >
> >
> > I can confirm that the new fix prevents the exploit from working, with
> > no immediately visible side effects.
> >
> > Thanks,
> > Daniel
> >
>
> Can some one release a 2.6.17.6 ? I think many people are waiting at
> their keyboard to get their systems protected.
If they are waiting, they should use 2.6.17.5, as only Networkmanager is
reported to be having problems with it.
I'll release .6 in a bit, but it will take an hour or so to get it
uploaded and out to the mirrors...
thanks,
greg k-h
Miquel van Smoorenburg
Von Wolher <tril...@ns666.com> wrote:
>Daniel Drake wrote:
>> Hi Linus,
>>
>> Linus Torvalds wrote:
>>
>>> I did a slight modification of the patch I committed initially, in the
>>> face of the report from Marcel that the initial sledge-hammer approach
>>> broke his hald setup.
>>>
>>> See commit 9ee8ab9fbf21e6b87ad227cd46c0a4be41ab749b: "Relax /proc fix
>>> a bit", which should still fix the bug (can somebody verify? I'm 100%
>>> sure, but still..), but is pretty much guaranteed to not have any
>>> secondary side effects.
>>>
>>> It still leaves the whole issue of whether /proc should honor chmod AT
>>> ALL open, and I'd love to close that one, but from a "minimal fix"
>>> standpoint, I think it's a reasonable (and simple) patch.
>>>
>>> Marcel, can you check current git?
>>
>>
>> I can confirm that the new fix prevents the exploit from working, with
>> no immediately visible side effects.
>>
>> Thanks,
>> Daniel
>>
>
>Can some one release a 2.6.17.6 ? I think many people are waiting at
>their keyboard to get their systems protected.
# mount -o remount,nosuid /proc
Haven't tested it but that should be the workaround.
Mike.
Marcel Holtmann
> >> I can confirm that the new fix prevents the exploit from working, with
> >> no immediately visible side effects.
> >
> >Can some one release a 2.6.17.6 ? I think many people are waiting at
> >their keyboard to get their systems protected.
>
> # mount -o remount,nosuid /proc
>
> Haven't tested it but that should be the workaround.
I did test it. And yes, it works.
Regards
Marcel
Matthew Frost
> On Fri, Jul 14, 2006 at 08:28:34PM -0700, Greg KH wrote:
>> On Fri, Jul 14, 2006 at 08:00:47PM -0700, Greg KH wrote:
>>> We (the -stable team) are announcing the release of the 2.6.17.5 kernel.
>> Oops, please note that we now have some reports that this patch breaks
>> some versions of HAL. So if you're relying on HAL, you might not want
>> to use this fix just yet (please evaluate the risks of doing this on
>> your own.)
>
> Hm, HAL 0.5.7 seems to work fine for me. Anyone else seeing any
> problems with this version? Older versions?
>
I'm running 0.5.7 and also see no problems.
FTR, I'm invoking
/usr/sbin/hald --daemon=yes --verbose=yes --use-syslog
and /var/log/messages looks no different than usual (last under 2.6.17.3).
> thanks,
>
> greg k-h
NP
Matt
Marcel Holtmann
> >>> We (the -stable team) are announcing the release of the 2.6.17.5 kernel.
> >> Oops, please note that we now have some reports that this patch breaks
> >> some versions of HAL. So if you're relying on HAL, you might not want
> >> to use this fix just yet (please evaluate the risks of doing this on
> >> your own.)
> >
> > Hm, HAL 0.5.7 seems to work fine for me. Anyone else seeing any
> > problems with this version? Older versions?
> >
>
> I'm running 0.5.7 and also see no problems.
>
> FTR, I'm invoking
>
> /usr/sbin/hald --daemon=yes --verbose=yes --use-syslog
>
> and /var/log/messages looks no different than usual (last under 2.6.17.3).
before this got spread around wrong. What I saw was an error window when
logging into Gnome. It said "failed to initialize HAL!". In fact it
seems that this is not a HAL error, it is an error of an application
using HAL and I suspect it was NetworkManager. However with 2.6.17.6 or
2.6.18-rc2 this is no problem anymore.
Regards
Marcel