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

« previous php.internals (#70599) next »