>From malloc(3):
Recent versions of Linux libc (later than 5.4.23) and GNU
libc (2.x) include a malloc implementation which is tun
able via environment variables. When MALLOC_CHECK_ is
set, a special (less efficient) implementation is used
which is designed to be tolerant against simple errors,
such as double calls of free() with the same argument, or
overruns of a single byte (off-by-one bugs). Not all such
errors can be proteced against, however, and memory leaks
can result. If MALLOC_CHECK_ is set to 0, any detected
heap corruption is silently ignored; if set to 1, a diag
nostic is printed on stderr; if set to 2, abort() is
called immediately. This can be useful because otherwise
a crash may happen much later, and the true cause for the
problem is then very hard to track down.
Setting MALLOC_CHECK_ in /etc/profile might be a good fix until all packages
are updated. It might hurt performance a little but probably not
significantly on a workstation. The following program demonstrates.
(WARNING: This program deliberately tries to corrupt the heap):
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char* argv[]) {
void* foo = malloc(16);
free(foo);
free(foo);
printf("Program ran to completion.\n");
}
Without MALLOC_CHECK_ set it segfaults before the printf. With
MALLOC_CHECK_=0 it does not segfault. With MALLOC_CHECK_=1 it prints an
annoying error message but proceeds to the printf. With MALLOC_CHECK_=2 it
prints "Abort" and terminates before the printf.
For various reasons, many packages (including the kernel) have chunks of
code copied from zlib rather than statically or dynamically linking with it,
so it could be quite a while before this bug is eradicated.
Krum
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Michael Riss
> Sent: Wednesday, March 13, 2002 6:20 AM
> To: [EMAIL PROTECTED]
> Subject: [Cooker] zlib malloc issue
>
>
> Hello
>
> it went over several newstickers yesterday, there is a bug
> in zlib-1.1.3. Certain input confuses the memory management
> of zlib, which leads to crashes or worse, might lead to the
> execution of arbitrary code.
>
> The full description is on:
>
> http://www.gzip.org/zlib/advisory-2002-03-11.txt
>
> There is a new version zlib-1.1.4, which fixes this problem.
> Unfortunatly there are some programs, which are statically linked
> to zlib, they have to be recompiled too.
> For a list of programs linking to zlib:
>
> http://www.gzip.org/zlib/apps.html
>
> Redhat has allready patches, including a patched kernel
> (kernel ppp compression is also using zlib):
>
> http://www.linuxsecurity.com/advisories/redhat_advisory-1963.html
>
> This issue might be important enough for 8.2 final, although
> many packages will be touched. Fixing it via patches leaves a
> bad taste, you buy the latest Mandrake and the first thing to do
> is updating a bunch of RPMs.
>
> I'm writing this here, because I did not see any postings to this
> issue 'til now (maybe I missed something) and the zlib on my
> mirror still is version zlib-1.1.3-19mdk.src.rpm.
>
> I hope you will find a good solution.
>
>
> cu
> Michi
>
