php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #33210 getimagesize() fails to detect width/height on certain JPEGs
Submitted: 2005-06-01 07:54 UTC Modified: 2010-06-30 14:21 UTC
Votes:7
Avg. Score:3.7 ± 1.4
Reproduced:6 of 6 (100.0%)
Same Version:3 (50.0%)
Same OS:3 (50.0%)
From: polone at townnews dot com Assigned: iliaa
Status: Closed Package: GetImageSize related
PHP Version: 4.3.11 OS: RedHat Linux 7.3
Private report: No CVE-ID:
 [2005-06-01 07:54 UTC] polone at townnews dot com
Description:
------------
The getimagesize() function fails on specific JPEG files. The reason is that php_next_marker() in:

ext/standard/image.c

has an artificial limit of 10 imposed on the number of 0xFF records that are found in sequential order. As far as I can tell ... the JPEG file format standards impose no such limit (see, http://www.jpeg.org/public/jfif.pdf). The proper behaviour should be to continue to read for the next marker until:

(1) M_SOS is found, in which case, image data has begun and no more headers will occur
(2) M_EOI has occurred (End of Image header) - this is the proper behavior in a properly encoded image
(3) EOF - something's wrong - but, at least it's not getimagesize()

I've provided an example of a JPEG file that will fail using getimagesize() online at:

http://www.townnews.com/contrib/premature.jpg

A fix is easily added by removing the artificial limit and just incrementing "a" in the marker's main loop around line 404:

if (++a > 10)
{
    /* who knows the maxim amount of 0xff? though 7 */
    /* but found other implementations              */
    return M_EOI;

}

I realize this may be in place to prevent infinite loops, but the reality is EOF will do that for us anyway. To fix the problem, just switch that code hunk too:

a++;

Reproduce code:
---------------
<?php

$sURL = "http://www.townnews.com/contrib/premature.jpg";
print_r(getimagesize($sURL));

?>

Expected result:
----------------
Array
(
    [0] => 350
    [1] => 603
    [2] => 2
    [3] => width="350" height="603"
    [bits] => 8
    [channels] => 3
    [mime] => image/jpeg
)



Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-06-02 00:29 UTC] iliaa@php.net
This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.


 [2005-07-27 23:18 UTC] polone at townnews dot com
This is NOT fixed. Raising the limit to 25 0xFF markers doesn't fix this issue - it merely fixes certain JPEGs that have less than 25 0xFF markers, but not all.
 [2010-05-07 19:36 UTC] dnavas at yahoo dot com
http://buckslocalnews.com/content/articles/2010/02/18/bucks_sports/doc4b6b385a8b4800059886291.jpg

a rises to 401.
I think polone's code and jfif.pdf link is worth another read.
 [2010-05-07 19:58 UTC] pajoye@php.net
-Status: No Feedback +Status: Open
 [2010-06-20 20:02 UTC] felipe@php.net
-Status: Open +Status: Assigned -Assigned To: +Assigned To: iliaa
 [2010-06-30 14:21 UTC] iliaa@php.net
Automatic comment from SVN on behalf of iliaa
Revision: http://svn.php.net/viewvc/?view=revision&amp;revision=300881
Log: Fixed bug #33210 (getimagesize() fails to detect width/height on certain JPEGs).
 [2010-06-30 14:21 UTC] iliaa@php.net
-Status: Assigned +Status: Closed
 [2010-06-30 14:21 UTC] iliaa@php.net
This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.


 
PHP Copyright © 2001-2014 The PHP Group
All rights reserved.
Last updated: Mon Apr 21 10:02:10 2014 UTC