As part of our fuzzing efforts at Google, we have identified an issue affecting
flif (tested with revision * master cfd25e57578ccd047dd2177aea2924f5a3fa1e5f).
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/
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:
=================================================================
==10==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000ed78 at pc 0x7f6414858c98 bp 0x7ffc5917bbb0 sp 0x7ffc5917bba8
READ of size 8 at 0x60200000ed78 thread T0
0x60200000ed78 is located 0 bytes to the right of 8-byte region [0x60200000ed70,0x60200000ed78)
allocated by thread T0 here:
0 0x505280 in operator new(unsigned long) (/fuzzing/FLIF/src/fuzzer+0x505280)
#1 0x7f6414a60b0f in void std::vector<std::unique_ptr<Transform<BlobReader>, std::default_delete<Transform<BlobReader> > >, std::allocator<std::unique_ptr<Transform<BlobReader>, std::default_delete<Transform<BlobReader> > > > >::_M_emplace_back_aux<std::unique_ptr<Transform<BlobReader>, std::default_delete<Transform<BlobReader> > > >(std::unique_ptr<Transform<BlobReader>, std::default_delete<Transform<BlobReader> > >&&) (/fuzzing/FLIF/src/libflif.so.0+0x35bb0f)
#2 0x7f64148dde4b in bool flif_decode<BlobReader>(BlobReader&, std::vector<Image, std::allocator<Image> >&, unsigned int (*)(unsigned int, long, unsigned char, void*, void*), void*, int, std::vector<Image, std::allocator<Image> >&, flif_options&, metadata_options&, FLIF_INFO*) (/fuzzing/FLIF/src/libflif.so.0+0x1d8e4b)
#3 0x7f6414bc12b7 in FLIF_DECODER::decode_memory(void const*, unsigned long) (/fuzzing/FLIF/src/libflif.so.0+0x4bc2b7)
#4 0x7f6414bc2378 in flif_decoder_decode_memory (/fuzzing/FLIF/src/libflif.so.0+0x4bd378)
#5 0x5085f5 in LLVMFuzzerTestOneInput /fuzzing/FLIF/src/fuzzer.cc:6:3
#6 0x50f17c in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/fuzzing/FLIF/src/fuzzer+0x50f17c)
#7 0x50864c in main (/fuzzing/FLIF/src/fuzzer+0x50864c)
SUMMARY: AddressSanitizer: heap-buffer-overflow (/fuzzing/FLIF/src/libflif.so.0+0x153c97) in int predict_and_calcProps_plane<Plane, Plane, false, false, 1, ColorRanges>(std::vector<int, std::allocator >&, ColorRanges const*, Image const&, Plane const&, Plane const&, int, unsigned int, unsigned int, int&, int&, int)
Shadow bytes around the buggy address:
0x0c047fff9d50: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff9d60: fa fa fa fa fa fa fa fa fa fa fa fa fa fa 00 04
0x0c047fff9d70: fa fa fd fd fa fa fd fa fa fa fd fd fa fa fd fa
0x0c047fff9d80: fa fa fd fd fa fa fd fa fa fa 00 00 fa fa 00 00
0x0c047fff9d90: fa fa 00 00 fa fa fd fd fa fa 00 00 fa fa 00 00
=>0x0c047fff9da0: fa fa 00 00 fa fa 00 00 fa fa 00 fa fa fa 00[fa]
0x0c047fff9db0: fa fa 00 00 fa fa fd fd fa fa fd fa fa fa fd fa
0x0c047fff9dc0: fa fa fd fd fa fa fd fa fa fa 04 fa fa fa 04 fa
0x0c047fff9dd0: fa fa 04 fa fa fa 04 fa fa fa 04 fa fa fa 04 fa
0x0c047fff9de0: fa fa 04 fa fa fa 04 fa fa fa 04 fa fa fa 04 fa
0x0c047fff9df0: fa fa 04 fa fa fa 04 fa fa fa 04 fa fa fa 04 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
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==10==ABORTING
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!
Hello flif team,
As part of our fuzzing efforts at Google, we have identified an issue affecting flif (tested with revision * master cfd25e57578ccd047dd2177aea2924f5a3fa1e5f).
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 /path/to/project
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:
================================================================= ==10==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000ed78 at pc 0x7f6414858c98 bp 0x7ffc5917bbb0 sp 0x7ffc5917bba8 READ of size 8 at 0x60200000ed78 thread T0
0 0x7f6414858c97 in int predict_and_calcProps_plane<Plane, Plane, false, false, 1, ColorRanges>(std::vector<int, std::allocator >&, ColorRanges const*, Image const&, Plane const&, Plane const&, int, unsigned int, unsigned int, int&, int&, int) (/fuzzing/FLIF/src/libflif.so.0+0x153c97)
0x60200000ed78 is located 0 bytes to the right of 8-byte region [0x60200000ed70,0x60200000ed78) allocated by thread T0 here:
0 0x505280 in operator new(unsigned long) (/fuzzing/FLIF/src/fuzzer+0x505280)
SUMMARY: AddressSanitizer: heap-buffer-overflow (/fuzzing/FLIF/src/libflif.so.0+0x153c97) in int predict_and_calcProps_plane<Plane, Plane, false, false, 1, ColorRanges>(std::vector<int, std::allocator >&, ColorRanges const*, Image const&, Plane const&, Plane const&, int, unsigned int, unsigned int, int&, int&, int)
Shadow bytes around the buggy address:
0x0c047fff9d50: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff9d60: fa fa fa fa fa fa fa fa fa fa fa fa fa fa 00 04
0x0c047fff9d70: fa fa fd fd fa fa fd fa fa fa fd fd fa fa fd fa
0x0c047fff9d80: fa fa fd fd fa fa fd fa fa fa 00 00 fa fa 00 00
0x0c047fff9d90: fa fa 00 00 fa fa fd fd fa fa 00 00 fa fa 00 00
=>0x0c047fff9da0: fa fa 00 00 fa fa 00 00 fa fa 00 fa fa fa 00[fa]
0x0c047fff9db0: fa fa 00 00 fa fa fd fd fa fa fd fa fa fa fd fa
0x0c047fff9dc0: fa fa fd fd fa fa fd fa fa fa 04 fa fa fa 04 fa
0x0c047fff9dd0: fa fa 04 fa fa fa 04 fa fa fa 04 fa fa fa 04 fa
0x0c047fff9de0: fa fa 04 fa fa fa 04 fa fa fa 04 fa fa fa 04 fa
0x0c047fff9df0: fa fa 04 fa fa fa 04 fa fa fa 04 fa fa fa 04 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
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==10==ABORTING
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_65527827.zip