Question about zend_hash.c, UPDATE_DATA macro

php.internals

Vesselin Atanasov

23 years ago
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?

Wez Furlong

23 years ago
I think I brought this up here before too. I can't remember the outcome - would you mind looking through the archives? --Wez.
> 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

Andi Gutmans

23 years ago
Just to make sure I understand what you're asking, are your first and second updates of data with different sizes? Andi At 02:50 PM 7/29/2003 +0300, Vesselin Atanasov wrote:

Andi Gutmans

23 years ago
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:

Jani Taskinen

23 years ago
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/business=sniper@php.net&no_note=1&tax=0&currency_code=EUR

Andi Gutmans

23 years ago
Sure, but I want to first make sure that the fix is OK. At 01:14 AM 7/31/2003 +0300, Jani Taskinen wrote: