#115 Integer overflow in exif/jpeg-data.c

exif (14)

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;


  • chendong

    chendong - 2013-01-08
    • summary: Integer overflow in exif/jpeg_data_save_data --> Integer overflow in exif/jpeg-data.c
  • chendong

    chendong - 2013-01-08

    *ds = 2^32-1 not 2^31-1
    just slip of the pen

  • Dan Fandrich

    Dan Fandrich - 2013-01-08

    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.

  • Dan Fandrich

    Dan Fandrich - 2013-01-08
    • status: open --> pending-invalid
  • Dan Fandrich

    Dan Fandrich - 2013-07-13
    • status: pending-invalid --> closed-invalid
    • assigned_to: Dan Fandrich
    • Group: -->

Log in to post a comment.