Date: Mon, 11 Mar 2002 23:40:30 +0100 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: hawkeyd@visi.com Cc: security at FreeBSD <freebsd-security@FreeBSD.ORG> Subject: Re: RedHat advisory - RHSA-2002:026-35 zlib double free -- Is this 4.5-R-p1? Message-ID: <64040.1015886430@critter.freebsd.dk> In-Reply-To: Your message of "Mon, 11 Mar 2002 15:44:24 CST." <20020311154424.A22882@sheol.localdomain>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20020311154424.A22882@sheol.localdomain>, D J Hawkey Jr writes:
>As the subjext asks, does the 4.5-RELEASE-p1 "zlib inflate error handling"
>fix the bug addressed by the RH advisory, or is FreeBSD's zlib vulnerable?
============================================================================
From: Poul-Henning Kamp <phk@freebsd.org>
Subject: the zlib double free bug
To: security-officer@freebsd.org
Message-Id: <58959.1015884837@critter.freebsd.dk>
Date: Mon, 11 Mar 2002 23:13:57 +0100
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
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?64040.1015886430>