You need to log in before you can comment on or make changes to this bug.
Created an attachment (id=774) [details] testcase On 4.0.7: # tiffsplit $FILE ==2007== Invalid read of size 4 ==2007== at 0x40CD1A: _TIFFVGetField (tif_dir.c:1072) ==2007== by 0x41B2C5: TIFFVGetField (tif_dir.c:1198) ==2007== by 0x41B2C5: TIFFGetField (tif_dir.c:1182) ==2007== by 0x404CCF: tiffcp (tiffsplit.c:220) ==2007== by 0x404CCF: main (tiffsplit.c:89) ==2007== Address 0x0 is not stack'd, malloc'd or (recently) free'd
The place of Out of bound read: ret_val = 0; for (i = 0; i < td->td_customValueCount; i++) { TIFFTagValue *tv = td->td_customValues + i; if (tv->info->field_tag != tag) continue;
The place of Out of bound read: The 1072 line of tif_dir.c 1068 ret_val = 0; 1069 for (i = 0; i < td->td_customValueCount; i++) { 1070 TIFFTagValue *tv = td->td_customValues + i; 1071 1072 if (tv->info->field_tag != tag) 1073 continue; As tv increased in 1070, Out of bound read happened in 1072 when the pointer tv was referenced.
PoC: Detailed information of the bug can be reproduced using the valgrind tool: # valgrind tiffsplit $File(the testcase in the attachment) Error Message: ==23520== Invalid read of size 4 ==23520== at 0x40CD1A: _TIFFVGetField (tif_dir.c:1072) ==23520== by 0x41B2C5: TIFFVGetField (tif_dir.c:1198) ==23520== by 0x41B2C5: TIFFGetField (tif_dir.c:1182) ==23520== by 0x404CCF: tiffcp (tiffsplit.c:220) ==23520== by 0x404CCF: main (tiffsplit.c:89) ==23520== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==23520== ==23520== ==23520== Process terminating with default action of signal 11 (SIGSEGV) ==23520== Access not within mapped region at address 0x0 ==23520== at 0x40CD1A: _TIFFVGetField (tif_dir.c:1072) ==23520== by 0x41B2C5: TIFFVGetField (tif_dir.c:1198) ==23520== by 0x41B2C5: TIFFGetField (tif_dir.c:1182) ==23520== by 0x404CCF: tiffcp (tiffsplit.c:220) ==23520== by 0x404CCF: main (tiffsplit.c:89) ==23520== If you believe this happened as a result of a stack ==23520== overflow in your program's main thread (unlikely but ==23520== possible), you can try to increase the size of the ==23520== main thread stack using the --main-stacksize= flag. ==23520== The main thread stack size used in this run was 8388608. ==23520== ==23520== HEAP SUMMARY: ==23520== in use at exit: 17,821 bytes in 42 blocks ==23520== total heap usage: 96 allocs, 54 frees, 59,223 bytes allocated ==23520== ==23520== LEAK SUMMARY: ==23520== definitely lost: 0 bytes in 0 blocks ==23520== indirectly lost: 0 bytes in 0 blocks ==23520== possibly lost: 0 bytes in 0 blocks ==23520== still reachable: 17,821 bytes in 42 blocks ==23520== suppressed: 0 bytes in 0 blocks ==23520== Rerun with --leak-check=full to see details of leaked memory ==23520== ==23520== For counts of detected and suppressed errors, rerun with: -v ==23520== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) Segmentation fault
Another occurence of http://bugzilla.maptools.org/show_bug.cgi?id=2580
Fixed per http://bugzilla.maptools.org/show_bug.cgi?id=2580