Hello tinyexr team,

As part of our fuzzing efforts at Google, we have identified an issue affecting
tinyexr (tested with revision * master 4ae1852).

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:
artifacts_71722583.zip

• mkdir project
• cp Dockerfile.tinyexr /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:

=================================================================
==11==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61700000f826 at pc 0x0000004b7525 bp 0x7ffe908f1a90 sp 0x7ffe908f1240
READ of size 69 at 0x61700000f826 thread T0
#0 0x4b7524 in __asan_memcpy (/fuzzing/tinyexr/fuzzer+0x4b7524)
#1 0x54c5e9 in tinyexr::rleUncompress(int, int, signed char const*, char*) /fuzzing/tinyexr/./tinyexr.h:7538:7
#2 0x549ad3 in tinyexr::DecompressRle(unsigned char*, unsigned long, unsigned char const*, unsigned long) /fuzzing/tinyexr/./tinyexr.h:7641:13
#3 0x54833b in tinyexr::DecodePixelData(unsigned char**, int const*, unsigned char const*, unsigned long, int, int, int, int, int, int, int, int, unsigned long, unsigned long, _EXRAttribute const*, unsigned long, _EXRChannelInfo const*, std::vector<unsigned long, std::allocator > const&) /fuzzing/tinyexr/./tinyexr.h:9670:5
#4 0x53ceed in tinyexr::DecodeChunk(_EXRImage*, _EXRHeader const*, std::vector<unsigned long, std::allocator > const&, unsigned char const*) /fuzzing/tinyexr/./tinyexr.h:10539:16
#5 0x532baf in tinyexr::DecodeEXRImage(_EXRImage*, _EXRHeader const*, unsigned char const*, unsigned char const*, unsigned long, char const**) /fuzzing/tinyexr/./tinyexr.h:10712:10
#6 0x53e827 in LLVMFuzzerTestOneInput /fuzzing/tinyexr/fuzzer.cc:20:9
#7 0x5100dc in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/fuzzing/tinyexr/fuzzer+0x5100dc)
#8 0x50f89e in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long) (/fuzzing/tinyexr/fuzzer+0x50f89e)
#9 0x5096fd in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*) (/fuzzing/tinyexr/fuzzer+0x5096fd)
#10 0x50abcf in fuzzer::FuzzerDriver(int*, char***, int ()(unsigned char const, unsigned long)) (/fuzzing/tinyexr/fuzzer+0x50abcf)
#11 0x5095ac in main (/fuzzing/tinyexr/fuzzer+0x5095ac)
#12 0x7f85601d22b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
#13 0x41ecb9 in _start (/fuzzing/tinyexr/fuzzer+0x41ecb9)

0x61700000f826 is located 0 bytes to the right of 678-byte region [0x61700000f580,0x61700000f826)
allocated by thread T0 here:
#0 0x5063d0 in operator new[](unsigned long) (/fuzzing/tinyexr/fuzzer+0x5063d0)
#1 0x51007d in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/fuzzing/tinyexr/fuzzer+0x51007d)
#2 0x5095ac in main (/fuzzing/tinyexr/fuzzer+0x5095ac)

SUMMARY: AddressSanitizer: heap-buffer-overflow (/fuzzing/tinyexr/fuzzer+0x4b7524) in __asan_memcpy
Shadow bytes around the buggy address:
0x0c2e7fff9eb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c2e7fff9ec0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c2e7fff9ed0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c2e7fff9ee0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c2e7fff9ef0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c2e7fff9f00: 00 00 00 00[06]fa fa fa fa fa fa fa fa fa fa fa
0x0c2e7fff9f10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c2e7fff9f20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c2e7fff9f30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c2e7fff9f40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c2e7fff9f50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
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
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==11==ABORTING

Please find a proposed patch in 0001-Fix-a-heap-OOB-read-in-DecodeChunk.zip

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