The file causing crash http://2000.lv/1.orig.jpg

yeah, please, build with -g, give us more info :), thanks

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  0x00002b6649bdd8fe in php_ifd_get16u (value=0xffffffffcc675e60, 
motorola_intel=0)
    at /home/huixinchen/opensource/php-5.3/ext/exif/exif.c:1095
1095			return (((uchar *)value)[1] << 8) | ((uchar *)value)[0];
(gdb) bt
#0  0x00002b6649bdd8fe in php_ifd_get16u (value=0xffffffffcc675e60, 
motorola_intel=0)
    at /home/huixinchen/opensource/php-5.3/ext/exif/exif.c:1095
#1  0x00002b6649bdeba8 in exif_iif_add_value (image_info=0x7fff7b6ec450, 
section_index=13, name=0x7fff7b6ebbb0 "CustomFunctions", tag=15, 
    format=3, length=12, value=0xffffffffcc675e60, motorola_intel=0) at 
/home/huixinchen/opensource/php-5.3/ext/exif/exif.c:1762
#2  0x00002b6649bded63 in exif_iif_add_tag (image_info=0x7fff7b6ec450, 
section_index=13, name=0x7fff7b6ebbb0 "CustomFunctions", tag=15, 
    format=3, length=12, value=0xffffffffcc675e60) at 
/home/huixinchen/opensource/php-5.3/ext/exif/exif.c:1812
#3  0x00002b6649be23e3 in exif_process_IFD_TAG (ImageInfo=0x7fff7b6ec450, 
dir_entry=0x1eb512d8 "\017", 
    offset_base=0xffffffffcc67493c <Address 0xffffffffcc67493c out of bounds>, 
IFDlength=13482, displacement=30, section_index=13, 
    ReadNextIFD=0, tag_table=0x2b6649de9b00) at /home/huixinchen/opensource/php-
5.3/ext/exif/exif.c:3135
#4  0x00002b6649be123b in exif_process_IFD_in_MAKERNOTE 
(ImageInfo=0x7fff7b6ec450, value_ptr=0x1eb512ca "\027", value_len=3476, 
    offset_base=0xffffffffcc67493c <Address 0xffffffffcc67493c out of bounds>, 
IFDlength=13482, displacement=30)
    at /home/huixinchen/opensource/php-5.3/ext/exif/exif.c:2813
#5  0x00002b6649be221f in exif_process_IFD_TAG (ImageInfo=0x7fff7b6ec450, 
dir_entry=0x1eb5085c "|\222\a", offset_base=0x1eb4fec0 "II*", 
    IFDlength=13482, displacement=30, section_index=7, ReadNextIFD=1, 
tag_table=0x2b6649de88e0)
    at /home/huixinchen/opensource/php-5.3/ext/exif/exif.c:3089
#6  0x00002b6649be256f in exif_process_IFD_in_JPEG (ImageInfo=0x7fff7b6ec450, 
dir_start=0x1eb507b2 "\037", offset_base=0x1eb4fec0 "II*", 
    IFDlength=13482, displacement=30, section_index=7) at 
/home/huixinchen/opensource/php-5.3/ext/exif/exif.c:3163
#7  0x00002b6649be2385 in exif_process_IFD_TAG (ImageInfo=0x7fff7b6ec450, 
dir_entry=0x1eb4ff36 "i\207\004", offset_base=0x1eb4fec0 "II*", 
    IFDlength=13482, displacement=30, section_index=3, ReadNextIFD=1, 
tag_table=0x2b6649de88e0)
    at /home/huixinchen/opensource/php-5.3/ext/exif/exif.c:3126
#8  0x00002b6649be256f in exif_process_IFD_in_JPEG (ImageInfo=0x7fff7b6ec450, 
dir_start=0x1eb4fec8 "\v", offset_base=0x1eb4fec0 "II*", 
    IFDlength=13482, displacement=30, section_index=3) at 
/home/huixinchen/opensource/php-5.3/ext/exif/exif.c:3163
#9  0x00002b6649be285a in exif_process_TIFF_in_JPEG (ImageInfo=0x7fff7b6ec450, 
CharBuf=0x1eb4fec0 "II*", length=13482, displacement=30)
    at /home/huixinchen/opensource/php-5.3/ext/exif/exif.c:3240
#10 0x00002b6649be298c in exif_process_APP1 (ImageInfo=0x7fff7b6ec450, 
CharBuf=0x1eb4feb8 "4²Exif", length=13490, displacement=22)
    at /home/huixinchen/opensource/php-5.3/ext/exif/exif.c:3265
#11 0x00002b6649be2f1d in exif_scan_JPEG_header (ImageInfo=0x7fff7b6ec450) at 
/home/huixinchen/opensource/php-5.3/ext/exif/exif.c:3410
#12 0x00002b6649be3ffd in exif_scan_FILE_header (ImageInfo=0x7fff7b6ec450) at 
/home/huixinchen/opensource/php-5.3/ext/exif/exif.c:3792
#13 0x00002b6649be4c41 in exif_read_file (ImageInfo=0x7fff7b6ec450, 
FileName=0x1eb4b8e8 "/tmp/1.orig.jpg", read_thumbnail=0, read_all=0)
    at /home/huixinchen/opensource/php-5.3/ext/exif/exif.c:3931
#14 0x00002b6649be4e27 in zif_exif_read_data (ht=1, return_value=0x1eb4aac0, 
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1)
    at /home/huixinchen/opensource/php-5.3/ext/exif/exif.c:3984
#15 0x00000000008e7d95 in zend_do_fcall_common_helper_SPEC 
(execute_data=0x2b664a23b090)
    at /home/huixinchen/opensource/php-5.3/Zend/zend_vm_execute.h:320
#16 0x00000000008ed77c in ZEND_DO_FCALL_SPEC_CONST_HANDLER 
(execute_data=0x2b664a23b090)
    at /home/huixinchen/opensource/php-5.3/Zend/zend_vm_execute.h:1640
---Type <return> to continue, or q <return> to quit---

Rasmus, could you please look at this one? I have no enough knowledge of the exif 
things :)

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

seeing the same issue on php-5.4.7-10.fc17.x86_64 (Fedora 17)

Same situation with file:
http://dl.dropbox.com/u/7562584/Bugs/Php/bad_exif.jpeg

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.000000000 +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<offset_base) {
+#ifdef EXIF_DEBUG
+			exif_error_docref(NULL EXIFERR_CC, ImageInfo, E_NOTICE, "EXIF invalid: offset_base (x%016llX) exceed value_ptr (x%016llX)", offset_base, value_ptr);
+#endif
+			return FALSE;
+		}
 		/* 4 bytes or less and value is in the dir entry itself */
 		value_ptr = dir_entry+8;
 		offset_val= value_ptr-offset_base;
@@ -3724,6 +3731,12 @@ static int exif_process_IFD_in_TIFF(imag
 						exif_error_docref(NULL EXIFERR_CC, ImageInfo, E_NOTICE, "Next IFD: %s done", exif_get_sectionname(sub_section_index));
 #endif
 					} else {
+						if(dir_offset > 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)) {

Thanks! The patch really works!

Any update on this bug? I've also run into this same problem with using exif to read data from some jpeg's. The script dies with a segmentation fault. I've applied Dominic's patch manually and re-compiled, and it seems to fix the issue. Any eta on when it will make it to PHP source?

Cannot reproduce with PHP-5.4+

Problem exists for me in PHP 5.4.7 that I have installed here. Using the original poster's sample code and sample file (or my own sample file linked above) Apache crashed with this in the log:

[notice] Parent: child process exited with status 255 -- Restarting.
[notice] Apache/2.2.21 (Win32) PHP/5.4.7 configured -- resuming normal operations

Same here, using latest 5.5 or snaps:

php_exif.dll!php_ifd_get16u(void * value, int motorola_intel) Line 1095	C
php_exif.dll!exif_iif_add_value(image_info_type * image_info, int section_index, char * name, int tag, int format, int length, void * value, int motorola_intel, void * * * tsrm_ls) Line 1754	C
php_exif.dll!exif_process_IFD_TAG(image_info_type * ImageInfo, char * dir_entry, char * offset_base, unsigned int IFDlength, unsigned int displacement, int section_index, int ReadNextIFD, const tag_info_type * tag_table, void * * * tsrm_ls) Line 3111	C
php_exif.dll!exif_process_IFD_in_MAKERNOTE(image_info_type * ImageInfo, char * value_ptr, int value_len, char * offset_base, unsigned int IFDlength, unsigned int displacement, void * * * tsrm_ls) Line 2789	C
php_exif.dll!exif_process_IFD_TAG(image_info_type * ImageInfo, char * dir_entry, char * offset_base, unsigned int IFDlength, unsigned int displacement, int section_index, int ReadNextIFD, const tag_info_type * tag_table, void * * * tsrm_ls) Line 3064	C
php_exif.dll!exif_process_IFD_in_JPEG(image_info_type * ImageInfo, char * dir_start, char * offset_base, unsigned int IFDlength, unsigned int displacement, int section_index, void * * * tsrm_ls) Line 3139	C
php_exif.dll!exif_process_IFD_TAG(image_info_type * ImageInfo, char * dir_entry, char * offset_base, unsigned int IFDlength, unsigned int displacement, int section_index, int ReadNextIFD, const tag_info_type * tag_table, void * * * tsrm_ls) Line 3101	C
php_exif.dll!exif_process_IFD_in_JPEG(image_info_type * ImageInfo, char * dir_start, char * offset_base, unsigned int IFDlength, unsigned int displacement, int section_index, void * * * tsrm_ls) Line 3139	C
php_exif.dll!exif_process_TIFF_in_JPEG(image_info_type * ImageInfo, char * CharBuf, unsigned int length, unsigned int displacement, void * * * tsrm_ls) Line 3222	C
php_exif.dll!exif_process_APP1(image_info_type * ImageInfo, char * CharBuf, unsigned int length, unsigned int displacement, void * * * tsrm_ls) Line 3240	C
php_exif.dll!exif_scan_JPEG_header(image_info_type * ImageInfo, void * * * tsrm_ls) Line 3426	C
php_exif.dll!exif_scan_FILE_header(image_info_type * ImageInfo, void * * * tsrm_ls) Line 3767	C
php_exif.dll!exif_read_file(image_info_type * ImageInfo, char * FileName, int read_thumbnail, int read_all, void * * * tsrm_ls) Line 3908	C
php_exif.dll!zif_exif_read_data(int ht, _zval_struct * return_value, _zval_struct * * return_value_ptr, _zval_struct * this_ptr, int return_value_used, void * * * tsrm_ls) Line 3960	C

please note that this patch makes 64bit platforms crash due misuse of int (4 bytes) vs size_t (8bytes)

https://code.google.com/p/php52-backports/issues/detail?id=36
attaching fix to that ticket there

To expand on my last comment, the patch from Dominic fixed the SegFault, but caused other issues with reading the majority of the exif data. I was no longer able to read other meta-data including Orientation, and had to revert.

Here are some of the details from my setup:

CentOS 5.9 x86_64
PHP 5.5.4

- File -
<?
$array = exif_read_data('file.jpg');
print_r($array);
exit;
?>

- Output -
php test.php
PHP Warning:  exif_read_data(file.jpg): Incorrect APP1 Exif Identifier Code in /home/xoticspottest/site/test.php on line 2
Segmentation fault

- Strace php test.php -
...
read(3, "\377\330\377\340\0\20JFIF\0\1\1\1\0H\0H\0\0\377\341\v\273http://n"..., 8192) = 8192
write(2, "PHP Warning:  exif_read_data(101"..., 140PHP Warning:  exif_read_data(file.jpg): Incorrect APP1 Exif Identifier Code in /home/xoticspottest/site/test.php on line 2) = 140
read(3, "\0^\17\0\0\230\0\3\0\4\0\0\0^\23\0\0\231\0\4\0J\0\0\0f\23\0\0\232\0\4"..., 8192) = 8192
read(3, "\1\3\21\1\377\304\0\37\0\0\1\5\1\1\1\1\1\1\0\0\0\0\0\0\0\0\1\2\3\4\5\6"..., 8192) = 8192
mmap(NULL, 266240, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2acd7c444000
mmap(NULL, 266240, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2acd7c485000
close(3)                                = 0
mmap(NULL, 266240, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2acd7c4c6000
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++


If needed, email me for the sample jpg. I can't put it on a public URL due to licensing issues.

After trying to assist someone with this issue on their setup I decided to test it some on mine since the reports of it's existence are pretty varied.

Out of four images tested (one the person provided, and the three linked here), only ONE of the images actually caused a segfault on both of my two tested setups, and that was the bad_exif.jpeg file.

My two setups are a 5.4.14 source-compiled on a 32-bit Fedora 17, and a 5.4.20 source-compiled on a 64-bit Fedora 19, and as noted above none of the images EXCEPT the bad_exif.jpeg cause segfaults under either web access (lighttpd+php-fpm setup) or CLI called.

Rebuilt the 5.4.14 setup into debug to get the following;
(gdb) bt
#0  0x0831ecfc in mbfl_buffer_converter_new2 (from=0x8a4f790, to=0x0,
    buf_initsz=38)
    at /root/apps/php-5.4.14/ext/mbstring/libmbfl/mbfl/mbfilter.c:158
#1  0x08326684 in php_mb_zend_encoding_converter (to=0xbfffbeec,
    to_length=0xbfffb9c4, from=0xb765aa1e "", from_length=38, encoding_to=0x0,
    encoding_from=0x8a4f790)
    at /root/apps/php-5.4.14/ext/mbstring/mbstring.c:917
#2  0x0861feeb in zend_multibyte_encoding_converter (to=0xbfffbeec,
    to_length=0xbfffb9c4, from=0xb765aa1e "", from_length=38, encoding_to=0x0,
    encoding_from=0x8a4f790) at /root/apps/php-5.4.14/Zend/zend_multibyte.c:150
#3  0x082264ba in exif_process_user_comment (ImageInfo=0xbfffbe98,
    pszInfoPtr=0xbfffbeec, pszEncoding=0xbfffbef4, szValuePtr=0xb765aa1e "",
    ByteCount=38) at /root/apps/php-5.4.14/ext/exif/exif.c:2666
#4  0x08227270 in exif_process_IFD_TAG (ImageInfo=0xbfffbe98,
    dir_entry=0xb765a93a "\206\222\a", offset_base=0xb765a780 "II*",
    IFDlength=24564, displacement=12, section_index=7, ReadNextIFD=1,
    tag_table=0x8747f60) at /root/apps/php-5.4.14/ext/exif/exif.c:2972
#5  0x08227953 in exif_process_IFD_in_JPEG (ImageInfo=0xbfffbe98,
    dir_start=0xb765a86c "\031", offset_base=0xb765a780 "II*",
    IFDlength=24564, displacement=12, section_index=7)
    at /root/apps/php-5.4.14/ext/exif/exif.c:3138
#6  0x0822776f in exif_process_IFD_TAG (ImageInfo=0xbfffbe98,
    dir_entry=0xb765a7f6 "i\207\004", offset_base=0xb765a780 "II*",
    IFDlength=24564, displacement=12, section_index=3, ReadNextIFD=1,
    tag_table=0x8747f60) at /root/apps/php-5.4.14/ext/exif/exif.c:3101
#7  0x08227953 in exif_process_IFD_in_JPEG (ImageInfo=0xbfffbe98,
    dir_start=0xb765a788 "\n", offset_base=0xb765a780 "II*", IFDlength=24564,
    displacement=12, section_index=3)
    at /root/apps/php-5.4.14/ext/exif/exif.c:3138
#8  0x08227c06 in exif_process_TIFF_in_JPEG (ImageInfo=0xbfffbe98,
    CharBuf=0xb765a780 "II*", length=24564, displacement=12)
    at /root/apps/php-5.4.14/ext/exif/exif.c:3215
#9  0x08227ccc in exif_process_APP1 (ImageInfo=0xbfffbe98,
    CharBuf=0xb765a778 "_\374Exif", length=24572, displacement=4)
    at /root/apps/php-5.4.14/ext/exif/exif.c:3240
#10 0x08228235 in exif_scan_JPEG_header (ImageInfo=0xbfffbe98)
    at /root/apps/php-5.4.14/ext/exif/exif.c:3385
#11 0x0822906e in exif_scan_FILE_header (ImageInfo=0xbfffbe98)
    at /root/apps/php-5.4.14/ext/exif/exif.c:3767
#12 0x08229bd8 in exif_read_file (ImageInfo=0xbfffbe98,
    FileName=0xb756af78 "/home/www/sites/bad_exif.jpeg", read_thumbnail=0,
    read_all=0) at /root/apps/php-5.4.14/ext/exif/exif.c:3906
#13 0x08229db4 in zif_exif_read_data (ht=1, return_value=0xb7656d08,
    return_value_ptr=0x0, this_ptr=0x0, return_value_used=1)
    at /root/apps/php-5.4.14/ext/exif/exif.c:3959
#14 0x0863a1d6 in zend_do_fcall_common_helper_SPEC (execute_data=0xb763c074)
    at /root/apps/php-5.4.14/Zend/zend_vm_execute.h:643
#15 0x0863db9d in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0xb763c074)
    at /root/apps/php-5.4.14/Zend/zend_vm_execute.h:2225
#16 0x086398bf in execute (op_array=0xb76574e8)
    at /root/apps/php-5.4.14/Zend/zend_vm_execute.h:410
#17 0x0860708e in zend_execute_scripts (type=8, retval=0x0, file_count=3)
    at /root/apps/php-5.4.14/Zend/zend.c:1315
#18 0x085910cf in php_execute_script (primary_file=0xbffff434)
    at /root/apps/php-5.4.14/main/main.c:2492
#19 0x08698b2b in do_cli (argc=2, argv=0xbffff6a4)
    at /root/apps/php-5.4.14/sapi/cli/php_cli.c:988
#20 0x08699c01 in main (argc=2, argv=0xbffff6a4)
    at /root/apps/php-5.4.14/sapi/cli/php_cli.c:1364

I'm the one being assisted by nbishop; specific circumstances were:
* 32-bit ubuntu 10.04 , 32-bit custom-compiled PHP 5.5.5
* Unit test were called from CLI, consisted of a single exif_read_data command
* Crashing image can be found at http://178.79.135.16/static/segfault_image.jpg
* Crash repros 100% of the time.

After burning a handful of hours on this, I've worked around by nuking the VPS, and installing a 64-bit 12.04 Ubuntu. This failed to repro segfault on this, or any of the images attached above (yay).

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.

We're experiencing the same issue.

Any attempt to import this post into wordpress generated the same issue when it calles exif_read_date (for reference, wp-admin/includes/image.php, line 339):

$exif = @exif_read_data( $file );

Removing the EXIF data eliminates the issue.

I helped debug the issue for BoingBoing regarding exif_read_data() causing a segfault. 
This was on RHEL 6 PHP 5.4

Please describe your environment. The offending file is needed. could you upload them somewhere and link it?

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.

I'm using PHP Version 5.6.14-0+deb8u1 on virtual machine VMware with Debian 8.0 and Debian 8.2

Bug exists at this moment on lastest version.

$ uname -a
Linux grevus 4.2.5-1-ARCH #1 SMP PREEMPT Tue Oct 27 08:13:28 CET 2015 x86_64 GNU/Linux

$ php -v
PHP 5.6.15 (cli) (built: Nov 10 2015 20:22:58) 
Copyright (c) 1997-2015 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2015 Zend Technologies

$ cat test.php && echo "" && php test.php 
<?php
	exif_read_data('http://dl.dropbox.com/u/7562584/Bugs/Php/bad_exif.jpeg');

Segmentation fault (core dumped)

=====================
Still exists

I can very much reproduce this too with 5.6.

It looks like "encoding_to=0x0" in frame 2 is the problem.

Backtrace:

158		if (mbfl_convert_filter_get_vtbl(convd->from->no_encoding, convd->to->no_encoding) != NULL) {
(gdb) bt full
#0  0x000000000074bdd9 in mbfl_buffer_converter_new2 (from=0x1387300 <mbfl_encoding_jis>, to=0x0, buf_initsz=38)
    at /home/derick/dev/php/php-src.git/ext/mbstring/libmbfl/mbfl/mbfilter.c:158
        convd = 0x7fffe948cfa0
#1  0x0000000000754ca0 in php_mb_zend_encoding_converter (to=0x7fffffffc668, to_length=0x7fffffffc038, from=0x7fffe948f32e "", from_length=38, encoding_to=0x0, 
    encoding_from=0x1387300 <mbfl_encoding_jis>) at /home/derick/dev/php/php-src.git/ext/mbstring/mbstring.c:945
        string = {no_language = mbfl_no_language_neutral, no_encoding = mbfl_no_encoding_jis, val = 0x7fffe948f32e "", len = 38}
        result = {no_language = mbfl_no_language_uni, no_encoding = mbfl_no_encoding_pass, val = 0x0, len = 0}
        convd = 0x5800000001
        status = 0
        loc = 0
#2  0x0000000000ab6e3f in zend_multibyte_encoding_converter (to=0x7fffffffc668, to_length=0x7fffffffc038, from=0x7fffe948f32e "", from_length=38, encoding_to=0x0, 
    encoding_from=0x1387300 <mbfl_encoding_jis>) at /home/derick/dev/php/php-src.git/Zend/zend_multibyte.c:150
No locals.
#3  0x0000000000635c9b in exif_process_user_comment (ImageInfo=0x7fffffffc5f0, pszInfoPtr=0x7fffffffc668, pszEncoding=0x7fffffffc678, szValuePtr=0x7fffe948f32e "", 
    ByteCount=38) at /home/derick/dev/php/php-src.git/ext/exif/exif.c:2658
        a = 0
        decode = 0x7fffffffc060 "\200\301\377\377\377\177"
        len = 140737107259986
#4  0x0000000000636c54 in exif_process_IFD_TAG (ImageInfo=0x7fffffffc5f0, dir_entry=0x7fffe948f24a "\206\222\a", offset_base=0x7fffe948f090 "II*", IFDlength=24564, 
    displacement=12, section_index=7, ReadNextIFD=1, tag_table=0x13777a0 <tag_table_IFD>) at /home/derick/dev/php/php-src.git/ext/exif/exif.c:2969
        length = 140737107285952
        tag = 37510
        format = 7
        components = 46
        value_ptr = 0x7fffe948f326 "JIS"
        tagname = "FocalLength\000\000ce\000\000\000ixel\000\000$\371\245\000\000\000\000\000 \301\377\377\377\177\000\000N\370\245", '\000' <repeats 13 times>, "Ps\305\000\000\000\000"
        cbuf = "\320\300\377\377\377\177\000\000\230\363\245", '\000' <repeats 17 times>, "\232\006\000"
        outside = 0x0
        byte_count = 46
        offset_val = 662
        fpos = 6502854
        fgot = 140737488339328
        byte_count_signed = 46
        tmp_xp = 0x7fffe948f16c

Derick, is this still an issue? If so, could yu please provide the faulty image?

I've tested with <http://www.getid3.org/temp/62523.jpg>, and that
segfaulted with php-5.5.7-nts-Win32-VC11-x86 and earlier, but not
as of php-5.5.8-nts-Win32-VC11-x86. That lead me to a commit which
added tests for this bug[1]. This commit shortly follows the
merge of PR #293[2], where it is claimed that the PR is unrelated
to this bug. :?

<http://dl.dropbox.com/u/7562584/Bugs/Php/bad_exif.jpeg> however,
has been reported to segfault with 5.6.15, but I can't reproduce
that (neither on Windows nor on Linux); instead I get the warning
"Unable to open file" (which doesn't happen for the other image).

So perhaps we're dealing with two bugs here.

[1] <https://github.com/php/php-src/commit/2fa5f39>

$ uname -a
Linux grevus 4.6.4-1-ARCH #1 SMP PREEMPT Mon Jul 11 19:12:32 CEST 2016 x86_64 GNU/Linux
$ php -v
PHP 7.0.8 (cli) (built: Jun 22 2016 16:45:35) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
$ cat test.php && echo "" && php test.php
<?php

exif_read_data('http://dl.dropbox.com/u/7562584/Bugs/Php/bad_exif.jpeg');

Segmentation fault (core dumped)

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.

<?php
exif_read_data('http://dl.dropbox.com/u/7562584/Bugs/Php/bad_exif.jpeg');

Indeed, valgrind reports

| Conditional jump or move depends on uninitialised value(s)

In this case cert_captured is uninitialized in the check whether
peer_cert has to be freed[1]. After adding a proper initializer,
there are still memory leaks reported by valgrind (also when
file_get_contents() is used instead of exif_read_data() with the
unmodified C code).

Stas, could you have a look at this issue?

[1] <https://github.com/php/php-src/blob/PHP-7.0.9/ext/openssl/xp_ssl.c#L1893>

I'm not sure what this has to do with openssl (given that the URL is not HTTPS). But I'll check what happens with these images.

Sorry, unable to reproduce any issues on either 5.6 or 7.0 with either bad_exif.jpeg or  62523.jpg. No segfaults, not complaints, nothing.

Just changing original e-mail

> I'm not sure what this has to do with openssl (given that the
> URL is not HTTPS).

$ curl -I -s http://dl.dropbox.com/u/7562584/Bugs/Php/bad_exif.jpeg' | grep location
location: http://dl.dropboxusercontent.com/u/7562584/Bugs/Php/bad_exif.jpeg

> Sorry, unable to reproduce any issues on either 5.6 or 7.0 with
> either bad_exif.jpeg or 62523.jpg.

Reading the exif data from a local file shows no issues; the
problem is with the connection to the server. I've tested and
debugged with the 5.6 branch, but I assume the issue occurs also
with newer versions (PHP 7.0.8 on Windows gave a segfault).

Did you try stepping through php_openssl_enable_crypto[1]? In my
tests with exif_read_data(), cert_captured never got assigned
(because stream->context was NULL), but it was tested on line
1791[2].

When I used file_get_contents() instead of exif_read_data() in the
reproduce script, stream->context was set, so cert_captured is
properly initialized, but still valgrind reported memory leaks.

[1] <https://github.com/php/php-src/blob/PHP-5.6.24/ext/openssl/xp_ssl.c#L1669>
[2] <https://github.com/php/php-src/blob/PHP-5.6.24/ext/openssl/xp_ssl.c#L1791>

If exif it fine with the file data, then this is another bug for sure. Let's open a new issue and add specific info regarding the backtraces, valgrind output and such.

The fix for this bug has been committed.

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/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.