improve the check, avoid strlen on NULL

Changed the way MAKERNOTE is handled in case we do not have a matching signature (Remi).

Before this patch, exif_process_IFD_in_MAKERNOTE() would return false, then causing the rest of the E

Changed the way MAKERNOTE is handled in case we do not have a matching signature (Remi).

Before this patch, exif_process_IFD_in_MAKERNOTE() would return false, then causing the rest of the EXIF parsing to be interrupted. This is a regression from earlier which was most likely a part of a security fix for MAKERNOTE.

The new behavior is to instead of stopping to parse, to continue so we can still fetch data like thumbnail and GPS, thrus allowing yet unsupported formats to parse. If EXIF's debugging mode is enabled, a notice will display in case we do not match against a valid MAKERNOTE signature.

This should temporarily fix bug #72682 (exif_read_data() fails to read all data for some images) until I get around to debug it further.

(cherry picked from commit aabcb5481d9e717df77192dab2894468b9fc63b4)

show more ...

Fix bug #72618: NULL Pointer Dereference in exif_process_user_comment

Fix bug #72603: Out of bound read in exif_process_IFD_in_MAKERNOTE

Fixed compilation warnings

Fix #50845: exif_process_IFD_TAG: Use the right offset if reading from stream

When the location of the data is outside of the range we have
preloaded (for example, if it's before the beg

Fix #50845: exif_process_IFD_TAG: Use the right offset if reading from stream

When the location of the data is outside of the range we have
preloaded (for example, if it's before the beginning of the IFD
structure), we have to read it from the stream into a separate buffer.
The offset calculations in this case were incorrect, resulting in
bogus values being read for the affected fields (sometimes parts of
other fields, sometimes binary data).

The included test image, sourced from [1], is in the public domain.

[1] https://commons.wikimedia.org/wiki/File:U.S._Marines_Prepare_to_board_an_MV-22_Osprey_160509-M-AF202-041.jpg

show more ...

Fix bug #72094 - Out of bounds heap read access in exif header processing

Eliminate usages of _PP macros

These are either in debug code (fix them), commented out (drop
them) or in dead compatibility macros (drop them).

One usage was in php_stream_get_

Eliminate usages of _PP macros

These are either in debug code (fix them), commented out (drop
them) or in dead compatibility macros (drop them).

One usage was in php_stream_get_from_zval(), which we have not used
since at least PHP 5.2 and, judging from the fact that nobody
complained about it causing compile errors in PHP 7, nobody else
uses it either, so drop it.

There are still remaining uses in mysqli embedded and odbc birdstep.
These probably need to be dropped outright.

show more ...

Move semicolon into TSRMLS_CACHE_EXTERN/DEFINE

Also re bug #71575.

Happy new year (Update copyright to 2016)

Fix build in exif debug mode, p_name is a char*, not a zval**

Improve fix for #70385

Fix bug #70385 (Buffer over-read in exif_read_data with TIFF IFD tag byte value of 32 bytes)

switch to the unified globals accessor where appropriate

Use ZSTR_ API to access zend_string elements (this is just renaming without semantick changes).

Fix more proto comments

cleaning up the version macros

made ZEND_TSRMLS_CACHE_* macros look like function calls

which also comply with the current semantics for such macros

bump year

bump year

Bump year

Fix bug #68799: Free called on unitialized pointer

trailing whitespace removal

second shot on removing TSRMLS_*

first shot remove TSRMLS_* things