As part of our fuzzing efforts at Google, we have identified an issue affecting
flif (tested with revision * master d790731b4b0de0b57c28a6652f0e2131cdd70f37).
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:
ALARM: working on the last Unit for 25 seconds
and the timeout value is 25 (use -timeout=N to change)
==11== ERROR: libFuzzer: timeout after 25 seconds
#0 0x4da933 in __sanitizer_print_stack_trace (/fuzzing/FLIF/src/fuzzer+0x4da933)
#1 0x50d847 in fuzzer::Fuzzer::AlarmCallback() (/fuzzing/FLIF/src/fuzzer+0x50d847)
#2 0x7ff2e41140bf (/lib/x86_64-linux-gnu/libpthread.so.0+0x110bf)
#3 0x7ff2e381c77c in __write (/lib/x86_64-linux-gnu/libc.so.6+0xdb77c)
#4 0x7ff2e37b37e6 in _IO_file_write (/lib/x86_64-linux-gnu/libc.so.6+0x727e6)
#5 0x7ff2e37b2b31 (/lib/x86_64-linux-gnu/libc.so.6+0x71b31)
#6 0x7ff2e37b3f3d in _IO_file_xsputn (/lib/x86_64-linux-gnu/libc.so.6+0x72f3d)
#7 0x7ff2e378ac94 (/lib/x86_64-linux-gnu/libc.so.6+0x49c94)
#8 0x7ff2e3787ef4 in _IO_vfprintf (/lib/x86_64-linux-gnu/libc.so.6+0x46ef4)
#9 0x496cdf in __interceptor_vfprintf (/fuzzing/FLIF/src/fuzzer+0x496cdf)
#10 0x7ff2e4e29e08 in e_printf(char const*, ...) (/fuzzing/FLIF/src/libflif.so.0+0x483e08)
#11 0x7ff2e4ba5035 in int read_chunk<BlobReader>(BlobReader&, MetaData&) (/fuzzing/FLIF/src/libflif.so.0+0x1ff035)
#12 0x7ff2e4b9d673 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+0x1f7673)
#13 0x7ff2e4e47917 in FLIF_DECODER::decode_memory(void const*, unsigned long) (/fuzzing/FLIF/src/libflif.so.0+0x4a1917)
#14 0x7ff2e4e489d8 in flif_decoder_decode_memory (/fuzzing/FLIF/src/libflif.so.0+0x4a29d8)
#15 0x5085f5 in LLVMFuzzerTestOneInput /fuzzing/FLIF/src/flif_dec_fuzzer.cc:8:3
#16 0x50f17c in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/fuzzing/FLIF/src/fuzzer+0x50f17c)
#17 0x50e93e in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long) (/fuzzing/FLIF/src/fuzzer+0x50e93e)
#18 0x50879d in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*) (/fuzzing/FLIF/src/fuzzer+0x50879d)
#19 0x509c6f in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/fuzzing/FLIF/src/fuzzer+0x509c6f)
#20 0x50864c in main (/fuzzing/FLIF/src/fuzzer+0x50864c)
#21 0x7ff2e37612b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
#22 0x41dd09 in _start (/fuzzing/FLIF/src/fuzzer+0x41dd09)
SUMMARY: libFuzzer: timeout
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.
The root cause appears to be that when an unknown chunk is read by read_chunk at EOF, the return value to flif_decode causes decoding to enter an infinite loop.
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 d790731b4b0de0b57c28a6652f0e2131cdd70f37).
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 projectcp Dockerfile.flif /path/to/project/Dockerfiledocker build --no-cache /path/to/projectdocker run -it image_id_from_docker_buildFrom 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/reproducerAlternatively, 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:
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.
The root cause appears to be that when an unknown chunk is read by read_chunk at EOF, the return value to flif_decode causes decoding to enter an infinite loop.
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_72828167.zip