Re: EXIF integer overflow again

From: Date: Thu, 12 Dec 2013 06:07:38 +0000
Subject: Re: EXIF integer overflow again
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-70599@lists.php.net to get a copy of this message
On Thu, Dec 12, 2013 at 7:01 AM, Tim Starling <tstarling@wikimedia.org> wrote:
> On 09/12/13 10:42, Stas Malyshev wrote:
>> Hi!
>>
>>> I just wanted to plug https://bugs.php.net/bug.php?id=65873 , since
>>> it's been a month since I filed it and I've only had silence in
>>> response, despite sending a private email to Stas about it.
>> Could you check out this patch: https://github.com/php/php-src/pull/539
>> It should fix this scenario.
>
> I commented there.
>
>> I couldn't add a test though since only
>> reproducing case is a 120M file and even for that special conditions are
>> required. If you have better reproduction that could be used on test
>> that would be most welcome.
>
> Well, reproduction requires that the file be bigger than the heap
> pointer, so to reproduce reliably, you really need both a large file
> and some control over the heap pointer. I think the best you could do
> in a .phpt would be to use an ENV section to customise the allocator,
> then craft a highly compressible TIFF file and gzinflate() it to a
> temporary directory during test execution. But even that would be
> system-dependent.

In any case, we can live without a test for this fix, better to have
it without test than no fix at all.

But generating it at runtime during the test run sounds like a good
solution. While I am not sure yet about a good way to craft a TIFF to
fit the crash requirements, we have no API to get the heap size (not
sure it is displayed by bintools).

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org


Thread (6 messages)

« previous php.internals (#70599) next »