Improper bounds checking on vector access (72413918)

[Google-Autofuzz]

Hello OpenEXR team,

As part of our fuzzing efforts at Google, we have identified an issue affecting
OpenEXR (tested with revision * develop 165dcea).

To reproduce, we are attaching a Dockerfile which compiles the project with
LLVM, taking advantage of the sanitizers that it offers. More information about
how to use the attached Dockerfile can be found here:
https://docs.docker.com/engine/reference/builder/

TL;DR instructions:

• mkdir project
• cp Dockerfile.OpenEXR /path/to/project/Dockerfile
• docker build --no-cache /path/to/project
• docker run -it image_id_from_docker_build

From another terminal, outside the container:
docker cp /path/to/attached/reproducer running_container_hostname:/fuzzing/reproducer
(reference: https://docs.docker.com/engine/reference/commandline/cp/)

And, back inside the container:
/fuzzing/repro.sh /fuzzing/reproducer

Alternatively, and depending on the bug, you could use gcc, valgrind or other
instrumentation tools to aid in the investigation. The sanitizer error that we
encountered is here:

/usr/bin/../lib/gcc/x86_64-linux-gnu/6.3.0/../../../../include/c++/6.3.0/debug/vector:415:
Error: attempt to subscript container with out-of-bounds index 0, but 
container only holds 0 elements.

Objects involved in the operation:
    sequence "this" @ 0x0x61600000e568 {
      type = std::__debug::vector<unsigned long, std::allocator<unsigned long> >;
    }
==21== ERROR: libFuzzer: deadly signal
    #0 0x4e25a3 in __sanitizer_print_stack_trace (/fuzzing/openexr_fuzz_scanlines+0x4e25a3)
    #1 0x5154ea in fuzzer::Fuzzer::CrashCallback() (/fuzzing/openexr_fuzz_scanlines+0x5154ea)
    #2 0x5154ba in fuzzer::Fuzzer::StaticCrashSignalCallback() (/fuzzing/openexr_fuzz_scanlines+0x5154ba)
    #3 0x7f3bfff6b0bf  (/lib/x86_64-linux-gnu/libpthread.so.0+0x110bf)
    #4 0x7f3bff5cafce in gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x32fce)
    #5 0x7f3bff5cc3f9 in abort (/lib/x86_64-linux-gnu/libc.so.6+0x343f9)
    #6 0x7f3c0053255a in __gnu_debug::_Error_formatter::_M_error() const (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0xb755a)
    #7 0x5b9f44 in std::__debug::vector<unsigned long, std::allocator<unsigned long> >::operator[](unsigned long) /usr/bin/../lib/gcc/x86_64-linux-gnu/6.3.0/../../../../include/c++/6.3.0/debug/vector:415:2
    #8 0x652950 in Imf_2_2::(anonymous namespace)::readPixelData(Imf_2_2::InputStreamMutex*, Imf_2_2::ScanLineInputFile::Data*, int, char*&, int&) /fuzzing/openexr/OpenEXR/IlmImf/ImfScanLineInputFile.cpp:379:24
    #9 0x651d5e in Imf_2_2::(anonymous namespace)::newLineBufferTask(IlmThread_2_2::TaskGroup*, Imf_2_2::InputStreamMutex*, Imf_2_2::ScanLineInputFile::Data*, int, int, int, Imf_2_2::OptimizationMode) /fuzzing/openexr/OpenEXR/IlmImf/ImfScanLineInputFile.cpp:1033:14
    #10 0x651540 in Imf_2_2::ScanLineInputFile::readPixels(int, int) /fuzzing/openexr/OpenEXR/IlmImf/ImfScanLineInputFile.cpp:1612:44
    #11 0x633995 in Imf_2_2::InputFile::readPixels(int, int) /fuzzing/openexr/OpenEXR/IlmImf/ImfInputFile.cpp:815:23
    #12 0x52500b in (anonymous namespace)::readMulti(char const*) /fuzzing/security-research-pocs/autofuzz/openexr_fuzz_scanlines.cc:75:54
    #13 0x52480d in LLVMFuzzerTestOneInput /fuzzing/security-research-pocs/autofuzz/openexr_fuzz_scanlines.cc:114:3
    #14 0x516d9c in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/fuzzing/openexr_fuzz_scanlines+0x516d9c)
    #15 0x51655e in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long) (/fuzzing/openexr_fuzz_scanlines+0x51655e)
    #16 0x5103bd in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*) (/fuzzing/openexr_fuzz_scanlines+0x5103bd)
    #17 0x51188f in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/fuzzing/openexr_fuzz_scanlines+0x51188f)
    #18 0x51026c in main (/fuzzing/openexr_fuzz_scanlines+0x51026c)
    #19 0x7f3bff5b82b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
    #20 0x425979 in _start (/fuzzing/openexr_fuzz_scanlines+0x425979)

NOTE: libFuzzer has rudimentary signal handlers.
      Combine libFuzzer with AddressSanitizer or similar for better crash reports.
SUMMARY: libFuzzer: deadly signal

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.

A patch for this issue is attached for your consideration.

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 eligible for inclusion to
the OSS-Fuzz project, which can provide additional continuous fuzzing, and
encourage you to investigate integration options.

Don't hesitate to let us know if you have any questions!

Google AutoFuzz Team

artifacts_72413918.zip
72413918.txt