Source: http://bugzilla.maptools.org/show_bug.cgi?id=2693 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 ------- Comment #1 From zhangtan 2017-05-15 01:20:26 ------- 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; ------- Comment #2 From zhangtan 2017-05-15 01:29:10 ------- 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. ------- Comment #3 From zhangtan 2017-05-15 01:46:33 ------- 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 Proof of Concept: https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/42301.zip