--- Begin Message ---
I just sent this to security-officer.
Please notice that if you have ports or applications linked with
other allocators than the libc malloc from FreeBSD this statement
does not apply.
Poul-Henning
------- Forwarded Message
To: [EMAIL PROTECTED]
Subject: the zlib double free bug
From: Poul-Henning Kamp <[EMAIL PROTECTED]>
Date: Mon, 11 Mar 2002 23:13:57 +0100
Message-ID: <[EMAIL PROTECTED]>
Sender: [EMAIL PROTECTED]
As author of our malloc(3) it is my opinion that we are not vulnerable to
this (kind of) bug.
Most mallocs keep their housekeeping data right next to the allocated
range. This gives rise to all sorts of unpleassant situations if
programs stray outside the dotted line, free(3) things twice or
free(3) modified pointers.
phkmalloc(3) does not store housekeeping next to allocated data,
and in particular it has code that detects and complains about
exactly the kind of double free this advisory talks about:
critter phk> cat a.c
main()
{
char *p;
p = malloc(256);
p = malloc(256);
free(p);
free(p);
}
critter phk> make a
cc -O -pipe a.c -o a
a.c: In function `main':
a.c:7: warning: assignment makes pointer from integer without a cast
a.c:8: warning: assignment makes pointer from integer without a cast
critter phk> ./a
a in free(): error: chunk is already free
Abort (core dumped)
critter phk>
The malloc flag 'A' determines if the situation is just warned about
or if the program should call abort(3).
- --
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
------- End of Forwarded Message
--- End Message ---
