You need to log in before you can comment on or make changes to this bug.
Created an attachment (id=777) [details] Crash reproducer Hello libtiff, As part of our fuzzing <https://www.owasp.org/index.php/Fuzzing> efforts at Google, we have identified an issue in version 4.0.7 (and latest from CVS) of libtiff. To reproduce requires compiling the project with the LLVM compiler, taking advantage of the sanitizers that it offers (this issue was discovered using AddressSanitizer <https://github.com/google/sanitizers/wiki/AddressSanitizer>). To reproduce you will need to build your project using that sanitizer, and execute the attached stub code on the reproducer input that we have also provided. This stub code could also serve as a useful template for fuzzing in your project with libFuzzer <http://libfuzzer.info> and/or AFL <http://lcamtuf.coredump.cx/afl/>, which may help you uncover additional issues. Some documentation on how to get started with libFuzzer is here: -Getting Started Documentation <http://llvm.org/docs/LibFuzzer.html#getting-started> -LibFuzzer Tutorial <http://llvm.org/docs/LibFuzzer.html#getting-started> -OSS-Fuzz target example <https://github.com/google/oss-fuzz/blob/a143b9b39a51412d133f846688194d68fe > 4197ba/projects/libchewing/chewing_default_fuzzer.c> The following options / environment variables may be necessary for accurate reproduction of the issue as well: ASAN_OPTIONS="exitcode=1,handle_segv=1,detect_leaks=1,leak_check_at_exit=1,a llocator_may_return_null=1,detect_odr_violation=0" MSAN_OPTIONS=... The sanitizer error that we encountered is here: ==133418==WARNING: AddressSanitizer failed to allocate 0xf00000008002c00 bytes Live Heap Allocations: 199438127 bytes from 3744 allocations; showing top 95% 117965568 byte(s) (59%) in 1 allocation(s) #0 0x4e6c1e in __interceptor_realloc #1 0x555788 in _TIFFCheckRealloc #2 0x5918b9 in Fax3SetupState #3 0x5495a2 in TIFFStartStrip #4 0x547a90 in TIFFReadEncodedStrip #5 0x4fc368 in TIFFReadContigStripData #6 0x4fd85d in TIFFReadData #7 0x4fbb49 in LLVMFuzzerTestOneInput #8 0x717f4d in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) #9 0x718160 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long) #10 0x7198cd in fuzzer::Fuzzer::MutateAndTestOne() #11 0x719b77 in fuzzer::Fuzzer::Loop() #12 0x70ea34 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) #13 0x71cbb2 in main #14 0x7f6a2b690ce7 in __libc_start_main #15 0x4283c8 in _start Other relevant info/repro instructions: We will gladly work with you so you can successfully confirm and reproduce this issue. Do let us know if you have any feedback surrounding the documentation. Once you have reproduced the issue, we’d appreciate to learn your expected timeline for an update to be released. With any fix, please attribute the report to “Google Autofuzz project”. We are also pleased to inform you that your project is also eligible for inclusion to the OSS-Fuzz project, which can provide additional continuous fuzzing, and encourage you to investigate integration options <https://github.com/google/oss-fuzz/blob/master/docs/new_project_guide.md>. Don’t hesitate to let us know if you have any questions! Google AutoFuzz Team
I doubt there is much to do on the libtiff side. The memory allocation is legit. Only an application level limitation could be set. This has been discussed in the following thread http://www.asmail.be/msg0055573667.html It is legit to have FAX3 encoded files with super small strip sizes (down to 4 bytes when the strip is made of a uniform color), that decompress to huge images.
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.
