Hi !
Linux 2.4.33.2 is out. It fixes a local privilege escalation in SCTP
(CVE-2006-3745). Also included are a fix for a bad address check in
binfmt_elf (already in 2.6), and a fix for build on some non-sparc
architectures which I broke in 2.4.33.1 when trying to fix the memchr()
export (problem reported by Mikael Pettersson).
If does not contain the UDF fix which went in 2.6.17.10. I will check
whether it applies to 2.4 and will backport it for a future release.
### Important note for users of Slackware 10.2 ###
Grant Coady informed me that 2.4.33.1 did not boot for him. After a long
series of tests from him and Pat Volkerding, it appeared that the problem
is caused by glibc 2.3.6 wrongly detecting kernel version as 4.33.1 and
mistakenly using the NTPL libs instead.
Patrick has fixed the problem and will (has ?) send the fix to the glibc
team. By now people using Slackware 10.2 must upgrade their glibc to
glibc-solibs-2.3.5-i486-6_slack10.2.tgz if they want to run a 2.4.33.x
kernel (user glibc-2.3.6 build -5 for -current). A workaround is either
to rename /lib/tls or to rename the kernel to something different than
4 numbers separated by dots. Since the problem is fixed, I don't intend
to change the numbering.
I dont think that this problem might affect many other distros since those
shipping an NPTL-enabled libc with both 2.4 and 2.6 mainline are rare. If
anyone else encounters the problem, Pat has the fix.
Regards,
Willy
Summary of changes from v2.4.33.1 to v2.4.33.2
============================================
Ernie Petrides:
binfmt_elf.c : fix checks for bad address
Sridhar Samudrala:
[SCTP] Local privilege elevation - CVE-2006-3745
Willy Tarreau:
Revert "export memchr() which is used by smbfs and lp driver."
[SPARC] export memchr() which is used by smbfs and lp driver.
Change VERSION to 2.4.33.2
On Tue, 22 Aug 2006 21:23:00 +0000, Willy Tarreau <[email protected]> wrote:
>
>Hi !
>
>Linux 2.4.33.2 is out. It fixes a local privilege escalation in SCTP
>(CVE-2006-3745). Also included are a fix for a bad address check in
>binfmt_elf (already in 2.6), and a fix for build on some non-sparc
>architectures which I broke in 2.4.33.1 when trying to fix the memchr()
>export (problem reported by Mikael Pettersson).
>
>If does not contain the UDF fix which went in 2.6.17.10. I will check
>whether it applies to 2.4 and will backport it for a future release.
>
>### Important note for users of Slackware 10.2 ###
>
>Grant Coady informed me that 2.4.33.1 did not boot for him. After a long
>series of tests from him and Pat Volkerding, it appeared that the problem
>is caused by glibc 2.3.6 wrongly detecting kernel version as 4.33.1 and
>mistakenly using the NTPL libs instead.
>
>Patrick has fixed the problem and will (has ?) send the fix to the glibc
>team. By now people using Slackware 10.2 must upgrade their glibc to
>glibc-solibs-2.3.5-i486-6_slack10.2.tgz if they want to run a 2.4.33.x
>kernel (user glibc-2.3.6 build -5 for -current). A workaround is either
>to rename /lib/tls or to rename the kernel to something different than
>4 numbers separated by dots. Since the problem is fixed, I don't intend
>to change the numbering.
>
>I dont think that this problem might affect many other distros since those
>shipping an NPTL-enabled libc with both 2.4 and 2.6 mainline are rare. If
>anyone else encounters the problem, Pat has the fix.
Okay here ;)
<http://bugsplatter.mine.nu/test/linux-2.4/>
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| kernel version |deltree|hal |niner |peetoo |pooh |sempro |silly |tosh |
+ - - - - - - - - + - - - + - - - + - - - + - - - + - - - + - - - + - - - + - - - +
| 2.4.33.2 [2] | - | Y | Y | Y | | Y | Y | Y |
| 2.4.33-2 [1] | Y | Y | Y | Y | | Y | Y | Y |
| 2.4.33-1 [1] | Y | Y | Y | Y | | Y | Y | Y |
| 2.4.33-final | Y | Y | Y | Y | | Y | Y | Y |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
[1] unofficial rename of 2.4.33.1 for testing under slackware, to be resolved...
[2] requires upgrade to glibc-solibs-2.3.5-i486-6_slack10.2.tgz for slack-10.2
Box deltree is halfway from slack-10.2 to slack-current, therefore not tested.
Cheers,
Grant.
On Tue, 22 Aug 2006 21:23:00 +0000, Willy Tarreau wrote:
>### Important note for users of Slackware 10.2 ###
>
>Grant Coady informed me that 2.4.33.1 did not boot for him. After a long
>series of tests from him and Pat Volkerding, it appeared that the problem
>is caused by glibc 2.3.6 wrongly detecting kernel version as 4.33.1 and
>mistakenly using the NTPL libs instead.
>
>Patrick has fixed the problem and will (has ?) send the fix to the glibc
>team. By now people using Slackware 10.2 must upgrade their glibc to
>glibc-solibs-2.3.5-i486-6_slack10.2.tgz if they want to run a 2.4.33.x
>kernel (user glibc-2.3.6 build -5 for -current). A workaround is either
>to rename /lib/tls or to rename the kernel to something different than
>4 numbers separated by dots. Since the problem is fixed, I don't intend
>to change the numbering.
>
>I dont think that this problem might affect many other distros since those
>shipping an NPTL-enabled libc with both 2.4 and 2.6 mainline are rare. If
>anyone else encounters the problem, Pat has the fix.
Can anyone provide a URL to the glibc fix?
While I don't use Slackware and haven't been bitten by
the bug (yet), I want to review the fix for possible
inclusion in my glibc patch kit.
/Mikael
Good question - all I can find is the slackware package - and it
appears not many mirrors have this yet:
http://slackware.it/en/pb/package.php?q=current/glibc-solibs-2.3.6-i486-5
Nick
On 27/08/06, Mikael Pettersson <[email protected]> wrote:
> On Tue, 22 Aug 2006 21:23:00 +0000, Willy Tarreau wrote:
> >### Important note for users of Slackware 10.2 ###
> >
> >Grant Coady informed me that 2.4.33.1 did not boot for him. After a long
> >series of tests from him and Pat Volkerding, it appeared that the problem
> >is caused by glibc 2.3.6 wrongly detecting kernel version as 4.33.1 and
> >mistakenly using the NTPL libs instead.
> >
> >Patrick has fixed the problem and will (has ?) send the fix to the glibc
> >team. By now people using Slackware 10.2 must upgrade their glibc to
> >glibc-solibs-2.3.5-i486-6_slack10.2.tgz if they want to run a 2.4.33.x
> >kernel (user glibc-2.3.6 build -5 for -current). A workaround is either
> >to rename /lib/tls or to rename the kernel to something different than
> >4 numbers separated by dots. Since the problem is fixed, I don't intend
> >to change the numbering.
> >
> >I dont think that this problem might affect many other distros since those
> >shipping an NPTL-enabled libc with both 2.4 and 2.6 mainline are rare. If
> >anyone else encounters the problem, Pat has the fix.
>
> Can anyone provide a URL to the glibc fix?
> While I don't use Slackware and haven't been bitten by
> the bug (yet), I want to review the fix for possible
> inclusion in my glibc patch kit.
>
> /Mikael
> -
> 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/
>
On Sun, Aug 27, 2006 at 03:50:29PM +0100, Nick Warne wrote:
> Good question - all I can find is the slackware package
I guess this is what you are looking for:
ftp://ftp.slackware.com/pub/slackware/slackware-current/source/l/glibc/glibc.kernelversion.diff.gz
On Sunday 27 August 2006 17:28, Petri Kaukasoina wrote:
> On Sun, Aug 27, 2006 at 03:50:29PM +0100, Nick Warne wrote:
> > Good question - all I can find is the slackware package
>
> I guess this is what you are looking for:
>
> ftp://ftp.slackware.com/pub/slackware/slackware-current/source/l/glibc/glib
>c.kernelversion.diff.gz
Good god - what a mess...
Nick
--
Every program has two purposes:
one for which it was written and another for which it wasn't.
On Sun, 27 Aug 2006 14:35:47 +0200 (MEST), Mikael Pettersson <[email protected]> wrote:
>On Tue, 22 Aug 2006 21:23:00 +0000, Willy Tarreau wrote:
...
>>I dont think that this problem might affect many other distros since those
>>shipping an NPTL-enabled libc with both 2.4 and 2.6 mainline are rare. If
>>anyone else encounters the problem, Pat has the fix.
>
>Can anyone provide a URL to the glibc fix?
For slack-10.2, look in:
<ftp://ftp.slackware.com/pub/slackware/slackware-10.2/patches/source/glibc>
Grant.
Nick Warne wrote:
> On Sunday 27 August 2006 17:28, Petri Kaukasoina wrote:
>> On Sun, Aug 27, 2006 at 03:50:29PM +0100, Nick Warne wrote:
>>> Good question - all I can find is the slackware package
>> I guess this is what you are looking for:
>>
>> ftp://ftp.slackware.com/pub/slackware/slackware-current/source/l/glibc/glib
>> c.kernelversion.diff.gz
>
> Good god - what a mess...
I agree, even though I'm not sure if you mean the original .h algorithm,
my fix, or glibc's system of reducing a Linux kernel version to a single
integer for easy comparison, though.
I'm glad my hack is getting some review. It's of the "ugly but probably
reliable" variety. More so than if I'd tried to fix the loop below
it... I felt it much safer to just fix the input string to give it
those "at most three parts" that it was designed for.
All the best,
Pat
On Tuesday 29 August 2006 22:09, Patrick J. Volkerding wrote:
> Nick Warne wrote:
> > On Sunday 27 August 2006 17:28, Petri Kaukasoina wrote:
> >> On Sun, Aug 27, 2006 at 03:50:29PM +0100, Nick Warne wrote:
> >>> Good question - all I can find is the slackware package
> >>
> >> I guess this is what you are looking for:
> >>
> >> ftp://ftp.slackware.com/pub/slackware/slackware-current/source/l/glibc/g
> >>lib c.kernelversion.diff.gz
> >
> > Good god - what a mess...
>
> I agree, even though I'm not sure if you mean the original .h algorithm,
> my fix, or glibc's system of reducing a Linux kernel version to a single
> integer for easy comparison, though.
>
> I'm glad my hack is getting some review. It's of the "ugly but probably
> reliable" variety. More so than if I'd tried to fix the loop below
> it... I felt it much safer to just fix the input string to give it
> those "at most three parts" that it was designed for.
My 'my god' bit was to glibc - not the fix! I bow down to you guys, seeing
what you had to do to suss it and get to work...
Where on earth did the assumption of 'three dots' come from anyway?
Nick
--
Every program has two purposes:
one for which it was written and another for which it wasn't.