This same problem likely exists in ZE1 too? Are you gonna fix it there? --Jani
On Wed, 30 Jul 2003, Andi Gutmans wrote: >Yes you are right. There indeed seems to be some flaw in the logic. I'll >commit a fix in a few minutes. >Please test it and let me know if it fixes your problems. > >Thanks, > >Andi > > >At 02:50 PM 7/29/2003 +0300, Vesselin Atanasov wrote: >>Hello. >>In PHP5, file zend_hash.c there is a macro >> >>#define UPDATE_DATA(ht, p, pData, nDataSize) >>\ >> if (nDataSize == sizeof(void*)) >>{ >>\ >> if (!(p)->pDataPtr) >>{ >>\ >> pefree((p)->pData, (ht)->persistent); >>\ >> } >>\ >> memcpy(&(p)->pDataPtr, pData, sizeof(void *)); >>\ >> (p)->pData = &(p)->pDataPtr; >>\ >> } else >>{ >>\ >> if ((p)->pDataPtr) >>{ >>\ >> (p)->pData = (void *) pemalloc(nDataSize, >>(ht)->persistent); \ >> (p)->pDataPtr=NULL; >>\ >> } >>\ >> memcpy((p)->pData, pData, nDataSize); >>\ >> } >> >>The macro is used to update a hash table element in >>zend_hash_add_or_update(). But it seems to me that if p->pData already >>points to a >>data block that hash size != sizeof (void *), and the macro is called to >>update the hash element with another block that has >>size != sizeof (void *), then the data block pointed at by p->pData will not >>be reallocated and the last memcpy() call will overwrite the old >>data block with the new data. This could possibly lead to memory corruption >>if the new block is bigger than the old block. >> >>Could any of the PHP developers comment on this? >> >> >>-- >>PHP Internals - PHP Runtime Development Mailing List >>To unsubscribe, visit: http://www.php.net/unsub.php > > > -- https://www.paypal.com/xclick/[EMAIL PROTECTED]&no_note=1&tax=0¤cy_code=EUR -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php