Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:10457 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 59129 invoked by uid 1010); 14 Jun 2004 20:51:25 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 59068 invoked from network); 14 Jun 2004 20:51:24 -0000 Received: from unknown (HELO e-matters.de) (217.69.76.213) by pb1.pair.com with SMTP; 14 Jun 2004 20:51:24 -0000 Received: (qmail 5171 invoked by uid 0); 14 Jun 2004 20:50:22 -0000 Received: from p508d625f.dip.t-dialin.net (HELO php.net) (80.141.98.95) by /var/run/qmail-smtp.pid with SMTP; 14 Jun 2004 20:50:22 -0000 Message-ID: <40CE0F51.9050908@php.net> Date: Mon, 14 Jun 2004 22:49:21 +0200 User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Schneider CC: ilia@prohost.org, internals@lists.php.net References: <200406141354.10937.ilia@prohost.org> <40CE0AF9.9070204@cschneid.com> In-Reply-To: <40CE0AF9.9070204@cschneid.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] basename() memory access violation From: sesser@php.net (Stefan Esser) Hi, > The function php_basename actually DOES access the char at s-1, i.e. one > byte before the string it is passed. If you hand it a buffer gotten from > malloc you get a valgrind hit. If I use emalloc this doesn't happen, I > guess emalloc has some header stuff before the allocation. If for > whatever reason s[-1] contains '/' then things would get even worse. First of all: yes it should be fixed, but it is nothing dangerous. emalloc stores the size of the buffer before the pointer you actually get. On little endian systems this means a '/' can only be directly before the buffer if this buffer is > 752MB big. For big endian systems this this is of course easier ;) Anyway this size is used only by the memory cache within the ZendEngine and by the memory_limit check. So by overwriting with a zero you could make the ZendEngine believe more memory is allocated that really is. <- No problem. The other thing could be that the block is inserted into the wrong cache position. Because we can only write 0 bytes this is no problem, because we would always insert the free memory block in a block that is assumed to be smaller (so no overflow possible). Stefan