Hello International Chemical Identifier (InChI) team,
As part of our fuzzing efforts at Google, we have identified an issue affecting
International Chemical Identifier (InChI) (tested with revision v1.04, September 2011). 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 /path/to/projectdocker 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/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:
ASAN:DEADLYSIGNAL
==9==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000006 (pc 0x00000065d71a bp 0x7fffaa89c170 sp 0x7fffaa89bd00 T0)
==9==The signal is caused by a READ memory access.
==9==Hint: address points to the zero page.
#0 0x65d719 in ParseSegmentConnections(char const*, int, tagINChI**, int*, int*) /fuzzing/INCHI-1-API/INCHI_API/inchi_dll/ichiread.c:7374:13
#1 0x653d12 in ReadInChILine(tagOutputStream*, tagLine*, char**, int*, tagINChI* (*) [2], int (*) [2], tagRemovedAndExchangeableH (*) [2], int (*) [2][2], int*, int*, unsigned char*) /fuzzing/INCHI-1-API/INCHI_API/inchi_dll/ichiread.c:4469:19
#2 0x64487b in InChILine2Data(tagOutputStream*, tagLine*, char**, int*, int*, tagINChI* (*) [2], int (*) [2], tagRemovedAndExchangeableH (*) [2], int (*) [2][2], int, int, unsigned long, int*, int*, unsigned char*) /fuzzing/INCHI-1-API/INCHI_API/inchi_dll/ichiread.c:2327:11
#3 0x642643 in ReadWriteInChI /fuzzing/INCHI-1-API/INCHI_API/inchi_dll/ichiread.c:571:23
#4 0x520e35 in GetINCHIfromINCHI /fuzzing/INCHI-1-API/INCHI_API/inchi_dll/inchi_dll.c:1953:16
#5 0x50911e in LLVMFuzzerTestOneInput /fuzzing/fuzzer.c:21:3
#6 0x5101fc in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/fuzzing/fuzzer+0x5101fc)
#7 0x50f9be in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long) (/fuzzing/fuzzer+0x50f9be)
#8 0x50982d in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*) (/fuzzing/fuzzer+0x50982d)
#9 0x50acff in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/fuzzing/fuzzer+0x50acff)
#10 0x5096dc in main (/fuzzing/fuzzer+0x5096dc)
#11 0x7f31ea9d72b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
#12 0x41e649 in _start (/fuzzing/fuzzer+0x41e649)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /fuzzing/INCHI-1-API/INCHI_API/inchi_dll/ichiread.c:7374:13 in ParseSegmentConnections(char const, int, tagINChI, int, int*)
==9==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
68418271