Sure, but I want to first make sure that the fix is OK.

At 01:14 AM 7/31/2003 +0300, Jani Taskinen wrote:

    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&currency_code=EUR



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Reply via email to