AcademySoftwareFoundation/openexr

Use-of-uninitialized-value in Imf_2_2::DeepScanLineInputFile::DeepScanLineInputFile

Google-Autofuzz opened this issue · 5 comments

Hello OpenEXR team,

As part of our fuzzing efforts at Google, we have identified an issue affecting
OpenEXR (tested with revision * master 76d9839).

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/

Instructions:

  • unzip artifacts_155906353.zip
  • docker build --build-arg SANITIZER=memory --tag=autofuzz-OpenEXR-155906353 autofuzz_155906353
  • docker run --entrypoint /fuzzing/repro.sh --cap-add=SYS_PTRACE -v $PWD/autofuzz_155906353/autofuzz_155906353:/tmp/poc autofuzz-OpenEXR-155906353 "exrenvmap" /tmp/poc
  • docker run --cap-add=SYS_PTRACE -v $PWD/autofuzz_155906353/autofuzz_155906353:/tmp/poc -it autofuzz-OpenEXR-155906353

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:

==8==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x7f721dec889b in std::_Rb_tree<char const*, std::pair<char const* const, Imf_2_5::Attribute* (*)()>, std::_Select1st<std::pair<char const* const, Imf_2_5::Attribute* (*)()> >, Imf_2_5::(anonymous namespace)::NameCompare, std::allocator<std::pair<char const* const, Imf_2_5::Attribute* (*)()> > >::_M_lower_bound(std::_Rb_tree_node<std::pair<char const* const, Imf_2_5::Attribute* (*)()> >*, std::_Rb_tree_node_base*, char const* const&) /usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/stl_tree.h:1887:7
    #1 0x7f721dec889b in std::_Rb_tree<char const*, std::pair<char const* const, Imf_2_5::Attribute* (*)()>, std::_Select1st<std::pair<char const* const, Imf_2_5::Attribute* (*)()> >, Imf_2_5::(anonymous namespace)::NameCompare, std::allocator<std::pair<char const* const, Imf_2_5::Attribute* (*)()> > >::find(char const* const&) /usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/stl_tree.h:2539
    #2 0x7f721dec889b in std::__cxx1998::map<char const*, Imf_2_5::Attribute* (*)(), Imf_2_5::(anonymous namespace)::NameCompare, std::allocator<std::pair<char const* const, Imf_2_5::Attribute* (*)()> > >::find(char const* const&) /usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/stl_map.h:1169
    #3 0x7f721dec889b in std::__debug::map<char const*, Imf_2_5::Attribute* (*)(), Imf_2_5::(anonymous namespace)::NameCompare, std::allocator<std::pair<char const* const, Imf_2_5::Attribute* (*)()> > >::find(char const* const&) /usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/debug/map.h:556
    #4 0x7f721dec889b in Imf_2_5::Attribute::registerAttributeType(char const*, Imf_2_5::Attribute* (*)()) /fuzzing/openexr/OpenEXR/IlmImf/ImfAttribute.cpp:116
    #5 0x7f721def6ca5 in Imf_2_5::TypedAttribute<Imath_2_5::Box<Imath_2_5::Vec2<int> > >::registerAttributeType() /fuzzing/openexr/OpenEXR/IlmImf/ImfAttribute.h:378:5
    #6 0x7f721def6ca5 in Imf_2_5::staticInitialize() /fuzzing/openexr/OpenEXR/IlmImf/ImfHeader.cpp:1266
    #7 0x7f721def69d8 in Imf_2_5::Header::Header(int, int, float, Imath_2_5::Vec2<float> const&, float, Imf_2_5::LineOrder, Imf_2_5::Compression) /fuzzing/openexr/OpenEXR/IlmImf/ImfHeader.cpp:146:5
    #8 0x4a24a6 in main /fuzzing/openexr/OpenEXR/exrenvmap/main.cpp:468:16
    #9 0x7f721d60209a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
    #10 0x420919 in _start (/fuzzing/openexr/build/bin/exrenvmap+0x420919)

SUMMARY: MemorySanitizer: use-of-uninitialized-value /usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/stl_tree.h:1887:7 in std::_Rb_tree<char const*, std::pair<char const* const, Imf_2_5::Attribute* (*)()>, std::_Select1st<std::pair<char const* const, Imf_2_5::Attribute* (*)()> >, Imf_2_5::(anonymous namespace)::NameCompare, std::allocator<std::pair<char const* const, Imf_2_5::Attribute* (*)()> > >::_M_lower_bound(std::_Rb_tree_node<std::pair<char const* const, Imf_2_5::Attribute* (*)()> >*, std::_Rb_tree_node_base*, char const* const&)
Exiting

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 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_155906353.zip

I'm confused by the "Imf_2_2::" in the title, that implies symbols from the 2.2 release, which you shouldn't have gotten from the master branch, and don't appear to occur in the stack trace. Is that a typo on your part? Just curious before digging further.

Further, the stack traces for #719, #720, #721, #722, #723 and #724 are all identical, and all point to use of uninitialized memory in the attribute map. (If there is an error there, it would be independent of the input file)

@cary-ilm It might be an issue with the build system on our side, yes.

@peterhillman It seems that something is wrong with the crash deduplication on our side, we're going to investigate, sorry about the noise.

The error report looks like a false positive, similar to this issue:
https://stackoverflow.com/questions/20617788/using-memory-sanitizer-with-libstdc
Clang's memory sanitizer needs a specially compiled libstdc++, but the Dockerfile suggests this setup just uses the standard build.

I get a similar error compiling the following snippet with clang++-7 -g -fsanitize=memory

#include <map>
int main(void)
{
        std::map<int,int> tMap;
        tMap[1] = 1;
        tMap[2] = 2;
}

valgrind also has an unintialized memory detector but doesn't report an issue with the OpenEXR library, so I suspect this is an issue with how MemorySanitizer was used, not OpenEXR

Closing, as this seems to be a result of incorrect sanitizer usage. Also note that the issue title is spurious, not related to the stack trace in question.