Description:
------------
exif_read_data() can crash or read data from arbitrary memory locations when presented with a large file with a tag value located before the relevant IFD. 

Throughout exif.c, the pointer offset_base is deliberately assigned a value before the start of its associated buffer. It is a kind of virtual start-of-file pointer -- when you add a file offset to offset_base, you get a pointer to the memory that holds the file data at that offset.

The bug occurs when the IFD offset is larger than the heap address for the file buffer. This only happens when both the heap address is small (e.g. if it is allocated from brk()) and the IFD offset is large. In this case, offset_base wraps around past the start of the address space and becomes a large positive pointer. This is mostly harmless, except for when a tag value is so far before the start of the IFD that its virtual pointer also wraps around to a large positive value. Then in exif_process_IFD_TAG():

if (byte_count > IFDlength || offset_val > IFDlength-byte_count || value_ptr < dir_entry) {

The "value_ptr < dir_entry" condition should be true, because the value is before the IFD in the file, but because value_ptr has wrapped around and dir_entry hasn't, it is false. So this code incorrectly assumes that value_ptr is inside the already-loaded buffer.

Our test file is here: https://noc.wikimedia.org/~reedy/segfault.tar.gz . It was generated innocently, it is not "crafted". 

This bug was originally reported here: https://bugzilla.wikimedia.org/show_bug.cgi?id=55541

Test script:
---------------
exif_read_data("/path/to/test.tiff");

The use of brk() for allocation instead of mmap() is required for reproduction, and is more reliable across various systems and builds if the environment variable ZEND_MM_SEG_SIZE=65536 is specified:

ZEND_MM_SEG_SIZE=65536 php -r 'exif_read_data("/path/to/test.tiff");'