Bug #62523 [Com]: php crashes with segfault when exif_read_data called
Edit report at https://bugs.php.net/bug.php?id=62523&edit=1
ID: 62523
Comment by: dominic dot benson at thirdlight dot com
Reported by:bigbug at mafia dot lv
Summary:php crashes with segfault when exif_read_data called
Status: Assigned
Type: Bug
Package:Reproducible crash
Operating System: linux
PHP Version:5.3Git-2012-07-10 (snap)
Assigned To:rasmus
Block user comment: N
Private report: N
New Comment:
I encountered a similar issue reading EXIF from a TIFF, the below patch fixes
both my original TIFF issue, and the issue with file "1.orig.jpg" linked in the
original report for me.
Environment: Linux amd64/i686 (Debian 5/6/7, Ubuntu 13.04)
PHP version: 5.3.25
SAPI: CLI/FastCGI
Required for the JPEG fix is a change from int type for offset_diff in
exif_process_IFD_in_MAKERNOTE. I've changed it to size_t, which is semantically
correct for Linux, but I think this isn't portable to Win.
Essentially, the issue is that values read from the file are treated as
offsets, and used to manipulate the offset_base.
Patch (agains 5.3.25) follows:
diff -rupN php-5.3.25.orig/ext/exif/exif.c php-5.3.25/ext/exif/exif.c
--- php-5.3.25.orig/ext/exif/exif.c 2013-05-08 16:58:52.0 +0100
+++ php-5.3.25/ext/exif/exif.c 2013-05-21 14:59:59.579438565 +0100
@@ -2745,7 +2745,8 @@ static int exif_process_unicode(image_in
static int exif_process_IFD_in_MAKERNOTE(image_info_type *ImageInfo, char *
value_ptr, int value_len, char *offset_base, size_t IFDlength, size_t
displacement TSRMLS_DC)
{
int de, i=0, section_index = SECTION_MAKERNOTE;
- int NumDirEntries, old_motorola_intel, offset_diff;
+ int NumDirEntries, old_motorola_intel;
+ size_t offset_diff;
const maker_note_type *maker_note;
char *dir_start;
@@ -2921,6 +2922,12 @@ static int exif_process_IFD_TAG(image_in
}
}
} else {
+ if (value_ptr
ImageInfo->file.list[sn].data) {
+#ifdef EXIF_DEBUG
+ exif_error_docref(NULL
EXIFERR_CC, ImageInfo, E_NOTICE, "Skip processing: dir_offset (x%016llX)
exceeds data pointer (x%016llX)", ImageInfo->file.list[sn].data, dir_offset);
+#endif
+ return FALSE;
+ }
if
(!exif_process_IFD_TAG(ImageInfo, (char*)dir_entry,
(char*)(ImageInfo->file.list[sn].data-dir_offset),
ifd_size, 0, section_index, 0, tag_table TSRMLS_CC)) {
Previous Comments:
[2012-12-12 12:33:03] dessander at gmail dot com
Same situation with file:
http://dl.dropbox.com/u/7562584/Bugs/Php/bad_exif.jpeg
[2012-10-30 13:26:09] alex at bartl dot net
seeing the same issue on php-5.4.7-10.fc17.x86_64 (Fedora 17)
[2012-09-14 17:25:50] info at getid3 dot org
I am also seeing the same problem on Windows (7-64-pro) running
php-5.4.7-nts-Win32-VC9-x86 (and previously same thing on v5.4.4)
I have only encountered one of my own files that causes the crash:
http://getid3.org/temp/62523.jpg
[2012-07-11 03:35:59] larue...@php.net
Rasmus, could you please look at this one? I have no enough knowledge of the
exif
things :)
[2012-07-11 03:33:59] larue...@php.net
I can reproduce this only in 5.3, seems 5.3 and 5.4 have the same exif code,
but can not reproduce this in 5.4.
#0 0x2b6649bdd8fe in php_ifd_get16u (value=0xcc675e60,
motorola_intel=0)
at /home/huixinchen/opensource/php-5.3/ext/exif/exif.c:1095
1095return (((uchar *)value)[1] << 8) | ((uchar *)value)[0];
(gdb) bt
#0 0x2b6649bdd8fe in php_ifd_get16u (value=0xcc675e60,
motorola_intel=0)
at /home/huixinchen/opensource/php-5.3/ext/exif/exif.c:1095
#1 0x2b6649bdeba8 in exif_iif_add_value (image_info=0x7fff7b6ec450,
section_index=13, name=0x7fff7b6ebbb0 "CustomFunctions", tag=15,
format=3, length=12, value=0xcc675e60, motorola_intel=0) at
/home/huixinchen/opensource/php-5.3/ext/exif/exif.c:1762
#2 0x2b6649bded63 in exif_iif_add_tag (image_info=0x7fff7b6ec450,
section_index=13, name=0x7fff7b6ebbb0 "CustomFunctions", tag=15,
format=3, length=12, value=0xcc675e60) at
/home/huixinc
Bug #60826 [Com]: raw POST data missing with chunked encoding, FastCGI
Edit report at https://bugs.php.net/bug.php?id=60826&edit=1 ID: 60826 Comment by: dominic dot benson at thirdlight dot com Reported by:clarkwise at gmail dot com Summary:raw POST data missing with chunked encoding, FastCGI Status: Assigned Type: Bug Package:CGI/CLI related Operating System: Windows XP PHP Version:5.3.9 Assigned To:ab Block user comment: N Private report: N New Comment: For Apache mod_fcgid, I have a patch available in the bug I filed at https://issues.apache.org/bugzilla/show_bug.cgi?id=53332 Essentially, PHP is following the spec, and not reading beyond the FastCGI CONTENT_LENGTH header value - so correct fixes are necessarily above PHP, in the FastCGI or web server implementation. Previous Comments: [2012-04-23 14:34:00] andres at fenestrae dot com @florian dot fernandez at navaho dot fr Florian, I'm afraid i cannot help you any further on Linux. The solution is not specific for Windows. What I did to tackle the problem at first is to write a small program that ran instead of php-cgi which copied whatever it received on stdin to an other a mailslot. This output I fed into php-cgi to reproduce an pinpoint the cause. Regards Andre [2012-04-23 10:59:25] florian dot fernandez at navaho dot fr Maybe I did something wrong but the patch doesn't seem to work with PHP 5.4.0 on Linux. [2012-04-23 08:08:19] florian dot fernandez at navaho dot fr Sorry, I didn't see it before. I'll give it a try with 5.4.0 [2012-04-23 08:00:32] andres at fenestrae dot com florian dot fernandez at navaho dot fr I have been able to try my solution in combination with 5.2.17. See the patches in this topic for the exact code-changes I made. [2012-04-23 07:52:12] florian dot fernandez at navaho dot fr @ andres at fenestrae dot com Have you been able to try what you suggested in your last post ? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=60826 -- Edit this bug report at https://bugs.php.net/bug.php?id=60826&edit=1
[PHP-BUG] Req #60129 [NEW]: Should be possible to set CURLOPT_CAPATH from php ini
From: Operating system: Any PHP version: 5.3.8 Package: cURL related Bug Type: Feature/Change Request Bug description:Should be possible to set CURLOPT_CAPATH from php ini Description: The ini setting curl.cainfo allows CURLOPT_CAINFO to be set automatically. It would be useful to allow CURLOPT_CAPATH to be set in the same fashion. The attached patch adds support for a new ini setting curl.capath, used to set CURLOPT_CAPATH when a new cURL resource is initialised. -- Edit bug report at https://bugs.php.net/bug.php?id=60129&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60129&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60129&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60129&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60129&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60129&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60129&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60129&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60129&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60129&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60129&r=support Expected behavior: https://bugs.php.net/fix.php?id=60129&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60129&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60129&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60129&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60129&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60129&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60129&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60129&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60129&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60129&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60129&r=mysqlcfg
Bug #59241 [Com]: Configure fails when compiled with php
Edit report at https://bugs.php.net/bug.php?id=59241&edit=1
ID: 59241
Comment by: dominic dot benson at thirdlight dot com
Reported by:magical...@php.net
Summary:Configure fails when compiled with php
Status: Open
Type: Bug
Package:uuid
Operating System: Linux
PHP Version:5.3.2
Block user comment: N
Private report: N
New Comment:
The oci8 extension has a somewhat comparable check (4.3.9<=version<6.0.0), so
I've borrowed and modified it for the patch.
Simply removing it wouldn't appear entirely unreasonable, though.
Previous Comments:
[2010-05-27 22:57:07] magical...@php.net
Description:
When compiling uuid with PHP (copy into ext dir and
regenerate configure) configure fails:
checking whether uuid is available... yes
checking for uuid_type in -luuid... yes
checking for uuid_variant in -luuid... yes
checking for uuid/uuid.h... yes
checking PHP version... configure: error: need at least PHP
4.0.0
The configure log shows:
configure:95377: checking PHP version
configure:95390: gcc -c -I/usr/include -g -O2 -
fvisibility=hidden -
I/home/magicaltux/projects/pinetd2/php/php-
5.3.2/ext/date/lib -
I/home/magicaltux/projects/pinetd2/php/php-
5.3.2/ext/ereg/regex -I/usr/include/libxml2 -
I/usr/include/imap -
I/home/magicaltux/projects/pinetd2/php/php-
5.3.2/ext/mbstring/oniguruma -
I/home/magicaltux/projects/pinetd2/php/php-
5.3.2/ext/mbstring/libmbfl -
I/home/magicaltux/projects/pinetd2/php/php-
5.3.2/ext/mbstring/libmbfl/mbfl -I/usr/include/mysql -
I/home/magicaltux/projects/pinetd2/php/php-
5.3.2/ext/sqlite3/libsqlite -I/include -DHAVE_UUID
conftest.c 1>&5
configure:95380:25: error: php_version.h: No such file or
directory
configure:95384:2: error: #error this extension requires at
least PHP version 4.0.0
configure: failed program was:
#line 95379 "configure"
#include "confdefs.h"
#include
int main() {
#if PHP_VERSION_ID < 4
#error this extension requires at least PHP version 4.0.0
#endif
; return 0; }
I'd guess the php 4.0.0 check can be safely dropped.
--
Edit this bug report at https://bugs.php.net/bug.php?id=59241&edit=1
Req #34750 [Com]: filesize()/stat() fails on too big files
Edit report at http://bugs.php.net/bug.php?id=34750&edit=1 ID: 34750 Comment by: dominic dot benson at thirdlight dot com Reported by:aulbach at mayflower dot de Summary:filesize()/stat() fails on too big files Status: Open Type: Feature/Change Request Package:Feature/Change Request Operating System: * PHP Version:5CVS,6CVS,4CVS (2008-02-22) Block user comment: N New Comment: The patch takes advantage of floats being doubles in PHP (with 53 bits of precision under linux 32) - in the patch LLONG_MAX is hardcoded as its actual value, this should really be derived from limits.h. It depends on PHP being built with the largefile compile flags to actually work (it fixes the integer wrapping that then occurs). It should be harmless on 64 bit, but ideally configure would check long vs. double on the system and include the additional section or not based on that. Previous Comments: [2005-10-06 10:38:36] aulbach at mayflower dot de - it's not a feature request, it's a workarround over a problem, that otherwise cannot be solved within PHP! (without calling external programs) - For longer term, there is no question, that PHP needs 64 bit integer. [2005-10-06 10:22:20] der...@php.net This is not a bug, but a feature request. [2005-10-06 10:08:18] aulbach at mayflower dot de Description: Writing a php command-line script, which scans all my files on my big raid, I mentioned, that PHP is not able to handle the case, when the files are bigger than 4 GB. But this is more and more used, cause for example complete DVD-images are just put in one file. PHP itself cannot handle bigger numbers, cause it uses 32 bit integer. Currently I help me with `ls` but that's no real solution. Everyone is using 64 bit integer now. There are many cases, timestamps for example. For now I suggest, that the number is stored as a string, if it gets too big. I use that number only to write it into the database (which can handle 64 bit int), so for that case this is correct. For long term, I suggest a mechanism, that automatically assigns 64 bit integer, if the number gets too big. Reproduce code: --- $fsize = filesize($path); // returns invalid if file is too big, the rest of the program will fail, if I assume, that there will be a number OR $stats = stat($path); // complete record invalid -- Edit this bug report at http://bugs.php.net/bug.php?id=34750&edit=1
Req #52679 [Com]: Content-length header is limited to 32bit integer
Edit report at http://bugs.php.net/bug.php?id=52679&edit=1 ID: 52679 Comment by: dominic dot benson at thirdlight dot com Reported by:dominic dot benson at thirdlight dot com Summary:Content-length header is limited to 32bit integer Status: Open Type: Feature/Change Request Package:Apache2 related Operating System: Linux 32 PHP Version:5.3.3 Block user comment: N New Comment: Correction to the above - clearly I mean strtol and strtoll rather than strtocol and strtocoll. Previous Comments: [2010-08-23 21:24:32] dominic dot benson at thirdlight dot com Description: As per #51723, the content-length header is limited to 2GB - however it need not be. If Apache 2.2 is built with -DLARGEFILE_SOURCE -DFILE_OFFSET_BITS=64 then apr_off_t is an off64_t, however the conversion in the calls to ap_set_content_length uses strtocol (hence limited to the 32-bit long on Linux 32), but if strtocoll is used instead to return a 64-bit long long, the header is set correctly for values > 2GB. The attached patch is of the adjustment, I guess the configure script generation needs to be updated to establish whether apr_off_t is long or long long. Test script: --- Expected result: A header: Content-Length: 100 Actual result: -- A header: Content-Length: 2147483647 -- Edit this bug report at http://bugs.php.net/bug.php?id=52679&edit=1
[PHP-BUG] Req #52679 [NEW]: Content-length header is limited to 32bit integer
From: Operating system: Linux 32 PHP version: 5.3.3 Package: Apache2 related Bug Type: Feature/Change Request Bug description:Content-length header is limited to 32bit integer Description: As per #51723, the content-length header is limited to 2GB - however it need not be. If Apache 2.2 is built with -DLARGEFILE_SOURCE -DFILE_OFFSET_BITS=64 then apr_off_t is an off64_t, however the conversion in the calls to ap_set_content_length uses strtocol (hence limited to the 32-bit long on Linux 32), but if strtocoll is used instead to return a 64-bit long long, the header is set correctly for values > 2GB. The attached patch is of the adjustment, I guess the configure script generation needs to be updated to establish whether apr_off_t is long or long long. Test script: --- Expected result: A header: Content-Length: 100 Actual result: -- A header: Content-Length: 2147483647 -- Edit bug report at http://bugs.php.net/bug.php?id=52679&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52679&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52679&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52679&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52679&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52679&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52679&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52679&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52679&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52679&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52679&r=support Expected behavior: http://bugs.php.net/fix.php?id=52679&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52679&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52679&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52679&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52679&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52679&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52679&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52679&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52679&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52679&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52679&r=mysqlcfg
