Through applying testing to the exif 0.6.21,
I found that libexif has an integer overflow bugs in
jpeg_data_save_data in exif/libjpeg/jpeg_data.c
in jpeg_data_save_data
The bug is in line 135. If the function input parameter *ds = 2^31-1,then (*ds + 2) is larger than UINT_MAX. (*ds + 2) becomes smaller due to integer overflow. Thus CLEANUP_REALLOC in line 135 only get one byte long memory.
(*d)[*ds + 0] = 0xff in line 136 may fail since it may access invalid memory address, which causes segmentation fault,or unexpected results.
Will not be function input parameter *ds so large to some reasons?
Please point out.
118 jpeg_data_save_data (JPEGData *data, unsigned char **d, unsigned int *ds)
。。。
135 CLEANUP_REALLOC (*d, sizeof (char) * (*ds + 2));
136 (*d)[*ds + 0] = 0xff;
137 (*d)[*ds + 1] = s.marker;
*ds = 2^32-1 not 2^31-1
just slip of the pen
I don't see how *ds could ever get close to UINT_MAX and therefore be in danger of overflow. The JPEGData structure passed in to jpeg_data_save_data, and which determines the final size of *ds, requires a pointer to heap allocated data for each JPEG section to write. So, for *ds to get close to UINT_MAX requires approximately the equivalent amount of memory to be allocated on the heap. But on a 32-bit machine, it's not possible to allocate UINT_MAX bytes on the heap, so *ds can't overflow. And on a 64-bit machine, UINT_MAX is so large there's no danger of it ever overflowing.