zlib vulnerability and modutils
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-Type: text/plain; charset=us-ascii
A double free vulnerability has been found in zlib which can be used in a DoS or possibly in an exploit. Distributions are now shipping upgraded versions of zlib, installing the new version of zlib will fix programs that use the shared library.
modutils has an option --enable-zlib which lets modprobe and insmod read modules that have been compressed with gzip. If you built your modutils with --enable-zlib and are using insmod.static then you must rebuild modutils after first upgrading zlib. This only applies if modutils was built with --enable-zlib (the default is not to use zlib) and you also use static versions of modutils.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Exmh version 2.1.1 10/15/1999
iD8DBQE8jTYQi4UHNye0ZOoRAnnhAKCrNZ2l8i1JHEVY3fJBnGYrpqAEBgCcDM0q tPtmhPq2fdJODlfzLlAatmU=
=8r7c
-----END PGP SIGNATURE-----
Quoted 6 lines · you [Keith Owens]
Content-Type: text/plain; charset=us-ascii
A double free vulnerability has been found in zlib which can be used in a DoS or possibly in an exploit. Distributions are now shipping upgraded versions of zlib, installing the new version of zlib will fix programs that use the shared library.
Is there a patch for the kernel ppp zlib implementation available somewhere? I'd like to patch the kernels I'm running rather than stuffing a random vendor kernel to the boxes...
-- v --
Quoted 3 lines · [email protected] said:
Is there a patch for the kernel ppp zlib implementation available
somewhere? I'd like to patch the kernels I'm running rather than stuffing a random vendor kernel to the boxes...
ftp://ftp.kernel.org/pub/linux/kernel/people/dwmw2/linux-2.4.19-shared-zlib.bz2
That's a backport of the shared zlib from 2.5.6. As it does all its memory allocation beforehand, I _assume_ it doesn't suffer the same problem.
It may be a little more intrusive than you wanted though.
--
dwmw2
Quoted 10 lines · you [David Woodhouse]
Quoted 3 lines · [email protected] said:
Is there a patch for the kernel ppp zlib implementation available
somewhere? I'd like to patch the kernels I'm running rather than stuffing a random vendor kernel to the boxes...ftp://ftp.kernel.org/pub/linux/kernel/people/dwmw2/linux-2.4.19-shared-zlib.bz2
That's a backport of the shared zlib from 2.5.6. As it does all its memory allocation beforehand, I _assume_ it doesn't suffer the same problem.
Thanks.
Quoted 1 line
It may be a little more intrusive than you wanted though.
Quite possibly -- at least considering that some of the kernels I run are still 2.2.x and even 2.0.x...
I'll have a look anyway.
-- v --
Quoted 5 lines · you [Ville Herva]
Quoted 2 lines
It may be a little more intrusive than you wanted though.
Quite possibly -- at least considering that some of the kernels I run are still 2.2.x and even 2.0.x...
I suppose this patch
http://cvs.samba.org/cgi-bin/cvsweb/rsync/zlib/infblock.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.6&f=u
i closer to what I need. It seems most vendors have only patched ppp's zlib implementation (drivers/net/zlib.c). I couldn't find that particular patch in redhat update kernel .src.rpm, tough. I guess I'll have to apply the zlib diff by hand.
-- v --
Quoted 7 lines · you [Ville Herva]
Quoted 5 lines · you [Ville Herva]
Quoted 2 lines
It may be a little more intrusive than you wanted though.
Quite possibly -- at least considering that some of the kernels I run are still 2.2.x and even 2.0.x...
Quoted 8 lines
I suppose this patch
http://cvs.samba.org/cgi-bin/cvsweb/rsync/zlib/infblock.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.6&f=u
is closer to what I need. It seems most vendors have only patched ppp's zlib implementation (
drivers/net/zlib.c). I couldn't find that particular patch in redhat update kernel .src.rpm, tough. I guess I'll have to apply the zlib diff by hand.
Ok, I found the following in the redhat errata kernel .src.rpm. It was well hidden in ipvs-1.0.6-2.2.19.patch... I guess this is the same that Arjan sent to Alan.
However, this does not apply to 2.0.
-- v --
drivers/net/zlib.c +7 -4
@@ -3860,10 +3860,11 @@ &s->sub.trees.tb, z);if (t !=Z_OK ) { -ZFREE (z, s->sub.trees.blens); r = t; -if (r ==Z_DATA_ERROR ) +if (r ==Z_DATA_ERROR ) { s->mode =BADB ; +ZFREE (z, s->sub.trees.blens); + } LEAVE } s->sub.trees.index =0 ;
@@ -3928,14 +3929,16 @@#endif t =inflate_trees_dynamic (257 + (t &0x1f ),1 + ((t >>5 ) &0x1f ), s->sub.trees.blens, &bl, &bd, &tl, &td, z); -ZFREE (z, s->sub.trees.blens);if (t !=Z_OK ) { -if (t == (uInt )Z_DATA_ERROR ) +if (t == (uInt )Z_DATA_ERROR ) { s->mode =BADB ; +ZFREE (z, s->sub.trees.blens); + } r = t; LEAVE } +ZFREE (z, s->sub.trees.blens);Tracev ((stderr,"inflate: trees ok, %d * %d bytes used\n" , inflate_hufts,sizeof (inflate_huft)));if ((c =inflate_codes_new (bl, bd, tl, td, z)) ==Z_NULL )
Quoted 7 lines · you [Keith Owens]
Content-Type: text/plain; charset=us-ascii
A double free vulnerability has been found in zlib which can be used in a DoS or possibly in an exploit. Distributions are now shipping upgraded versions of zlib, installing the new version of zlib will fix programs that use the shared library.
Quoted 6 lines
modutils has an option --enable-zlib which lets modprobe and insmod read modules that have been compressed with gzip. If you built your modutils with --enable-zlib and are using insmod.static then you must rebuild modutils after first upgrading zlib. This only applies if modutils was built with --enable-zlib (the default is not to use zlib) and you also use static versions of modutils.
I'm propably missing something, but if you load untrusted kernel modules (compressed or not), isn't the zlib vulnerability least of your concerns?
-- v --