#92 Corrupt reading of ExifEntry causes huge memcpy

Jan Patera
libexif (61)
Martin Nordholts

This bug report is forwarded from the GIMP bugtracker, and the bug in question is:
Bug 549029 – Particular JPEG causes GIMP to suck resources

Loading the attached image in GIMP when compiled with latest CVS libexif causes a memcpy of about 300 MB to occur. Stacktrace:

#0 0xb73239bc in memcpy () from /lib/tls/i686/cmov/libc.so.6
#1 0xb7443bd9 in exif_data_save_data_entry (data=0x8085500, e=0x80a7680,
d=0xbfd6b900, ds=0xbfd6b8fc, offset=398) at exif-data.c:282
#2 0xb74446aa in exif_data_save_data_content (data=0x8085500, ifd=0x8091498,
d=0xbfd6b900, ds=0xbfd6b8fc, offset=254) at exif-data.c:527
#3 0xb74447f2 in exif_data_save_data_content (data=0x8085500, ifd=0x80914e0,
d=0xbfd6b900, ds=0xbfd6b8fc, offset=118) at exif-data.c:551
#4 0xb7445b83 in exif_data_save_data (data=0x8085500, d=0xbfd6b900,
ds=0xbfd6b8fc) at exif-data.c:928
#5 0x08054dfc in gimp_metadata_store_exif (image_ID=1, exif_data=0x8085500) at
#6 0x0804ec5f in load_image (filename=0x8067400
"/home/martin/Desktop/Genesis_Wildlife1.jpg", runmode=GIMP_RUN_INTERACTIVE,
preview=0, error=0xbfd6bd44) at jpeg-load.c:331
#7 0x0804c86b in run (name=0x80662c0 "file-jpeg-load", nparams=3,
param=0x8066b80, nreturn_vals=0xbfd6bda4, return_vals=0xbfd6bda8) at jpeg.c:233
#8 0xb7d8a1f3 in gimp_proc_run (proc_run=0x805f840) at gimp.c:1893
#9 0xb7d89e93 in gimp_loop () at gimp.c:1727
#10 0xb7d8887a in gimp_main (info=0x8055080, argc=6, argv=0xbfd6bf34) at
#11 0x0804c55e in main (argc=Cannot access memory at address 0x1a9b448

And the failing ExifEntry looks like this:

{tag = EXIF_TAG_MAKER_NOTE, format = EXIF_FORMAT_UNDEFINED, components =
372526732, data = 0xa0bdf008 "Nikon", size = 372526732, parent = 0x8091498,
priv = 0x80a76a0}

At first I thought this was a duplicate of
[ 1599114 ] exif_data_save_data consuming all memory
but I was able to open the attached file just fine (with latest CVS libexif using GIMP).


  • Logged In: YES
    Originator: YES

    I seem to be unable to attach the file, please fetch it from the GIMP bug report.

    I would also like to add that the ExifEntry::size can vary, so it seems to be a read-error rather than bogus data in the file.

  • Jan Patera
    Jan Patera

    • assigned_to: nobody --> patera
    • status: open --> closed-fixed
  • Jan Patera
    Jan Patera

    The reported JPG file uses II word order, but contains original v1 Nikon makernote.
    When the file file was resaved, the makernote was not modified:
    a) original MM word order was left.
    b) offsets to entry data larger than 4 bytes are corrupted.
    When parsing original v1 Nikon makernotes, libexif now always assumes
    MM order, regardless of the parent EXIF order.
    NOTE: this will not cause any problem because original v1 makernotes
    do not have any real header, we detect them by merely checking if the
    first 2 bytes are 00 1b which mean the fixed number 27 of entries in MM order.
    In case somebody resaved the makernote in II order, he would saved 1b 00
    instead. libexif does not support such files, because they are never
    created by any camera and thus are not supposed to exist.

    NOTE: a more general "fix to huge memcpy's when saving makernotes" was commited
    just days ago by Lutz on behalf of Niek Bergboer.