You need to log in before you can comment on or make changes to this bug.
Created an attachment (id=771) [details] report.rar contains poc and a brief analysis of the vulnerability Did not check the user input BMP file. The program does not check for biWidth and biHeight in bitmap-information header. The biWidth and biHeight do not match the actual input of the bmp image causing the heap buffer overflow ================================================================= ==11044==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7f715afe4c00 at pc 0x6805e4 bp 0x7ffd7878c2d0 sp 0x7ffd7878c2c8 READ of size 1 at 0x7f715afe4c00 thread T0 ==11044==WARNING: Trying to symbolize code, but external symbolizer is not initialized! #0 0x6805e3 (/home/lolopop/projects/build-clang-build/libtiff/tools/bmp2tiff+0x6805e3) #1 0x5c1106 (/home/lolopop/projects/build-clang-build/libtiff/tools/bmp2tiff+0x5c1106) #2 0x48a155 (/home/lolopop/projects/build-clang-build/libtiff/tools/bmp2tiff+0x48a155) #3 0x7f7159ce9f44 (/lib/x86_64-linux-gnu/libc.so.6+0x21f44) #4 0x47e7cc (/home/lolopop/projects/build-clang-build/libtiff/tools/bmp2tiff+0x47e7cc) 0x7f715afe4c00 is located 0 bytes to the right of 1049600-byte region [0x7f715aee4800,0x7f715afe4c00) allocated by thread T0 here: #0 0x4686e9 (/home/lolopop/projects/build-clang-build/libtiff/tools/bmp2tiff+0x4686e9) #1 0x5d4447 (/home/lolopop/projects/build-clang-build/libtiff/tools/bmp2tiff+0x5d4447) #2 0x486289 (/home/lolopop/projects/build-clang-build/libtiff/tools/bmp2tiff+0x486289) #3 0x7f7159ce9f44 (/lib/x86_64-linux-gnu/libc.so.6+0x21f44) SUMMARY: AddressSanitizer: heap-buffer-overflow ??:0 ?? Shadow bytes around the buggy address: 0x0feeab5f4930: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0feeab5f4940: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0feeab5f4950: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0feeab5f4960: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0feeab5f4970: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x0feeab5f4980:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0feeab5f4990: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0feeab5f49a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0feeab5f49b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0feeab5f49c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0feeab5f49d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 ASan internal: fe ==11044==ABORTING Poc and analysis reports：
I must say I can't think of a worse way to provide plain text information for a bug report than taking a screen shot of a terminal, pasting it into a pdf, and then wrapping it in a rar archive. Please just use plain text when you can. In any case, isn't this "fixed" in libtiff 4.0.7 by the removal of the bmp2tiff program?
Bugzilla is no longer used for tracking libtiff issues. Remaining open tickets, such as this one, have been migrated to the libtiff GitLab instance at https://gitlab.com/libtiff/libtiff/issues . The migrated tickets have their summary prefixed with [BZ#XXXX] where XXXX is the initial Bugzilla issue number.
