Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Leak detection doesn't work #9

Closed
mikea opened this issue Oct 10, 2016 · 17 comments
Closed

Leak detection doesn't work #9

mikea opened this issue Oct 10, 2016 · 17 comments
Assignees

Comments

@mikea
Copy link
Contributor

mikea commented Oct 10, 2016

Leak detection is disabled because it always gives a false positive.

To reproduce:

docker run -ti -e ASAN_OPTIONS=detect_leaks=1 ossfuzz/expat run expat_parse_fuzzer -runs=100

This will generate lots of leaks like:

Indirect leak of 1 byte(s) in 1 object(s) allocated from:
    #0 0x50d000 in operator new(unsigned long) /src/llvm/projects/compiler-rt/lib/asan/asan_new_delete.cc:82
    #1 0x53fd89 in std::__1::__allocate(unsigned long) /usr/local/bin/../include/c++/v1/new:171:10
    #2 0x53fd89 in std::__1::allocator<unsigned char>::allocate(unsigned long, void const*) /usr/local/bin/../include/c++/v1/memory:1771
    #3 0x53fd89 in std::__1::allocator_traits<std::__1::allocator<unsigned char> >::allocate(std::__1::allocator<unsigned char>&, unsigned long) /usr/local/bin/../include/c++/v1/memory:1526
    #4 0x53fd89 in std::__1::vector<unsigned char, std::__1::allocator<unsigned char> >::allocate(unsigned long) /usr/local/bin/../include/c++/v1/vector:923
    #5 0x53f2a4 in _ZNSt3__16vectorIhNS_9allocatorIhEEE6assignIPhEENS_9enable_ifIXaasr21__is_forward_iteratorIT_EE5valuesr16is_constructibleIhNS_15iterator_traitsIS7_E9referenceEEE5valueEvE4typeES7_S7_ /usr/local/bin/../include/c++/v1/vector:1403:9
    #6 0x52d096 in std::__1::vector<unsigned char, std::__1::allocator<unsigned char> >::operator=(std::__1::vector<unsigned char, std::__1::allocator<unsigned char> > const&) /usr/local/bin/../include/c++/v1/vector:1348:9
    #7 0x52d096 in fuzzer::InputCorpus::AddToCorpus(std::__1::vector<unsigned char, std::__1::allocator<unsigned char> > const&, unsigned long, bool) /src/libfuzzer/FuzzerCorpus.h:71
    #8 0x583213 in fuzzer::Fuzzer::ShuffleAndMinimize(std::__1::vector<std::__1::vector<unsigned char, std::__1::allocator<unsigned char> >, std::__1::allocator<std::__1::vector<unsigned char, std::__1::allocator<unsigned char> > > >*) /src/libfuzzer/FuzzerLoop.cpp:427:14
    #9 0x52059f in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:519:5
    #10 0x5aac38 in main /src/libfuzzer/FuzzerMain.cpp:20:10
    #11 0x7f9b61f2982f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
@kcc
Copy link
Contributor

kcc commented Oct 11, 2016

Solution: add --cap-add SYS_PTRACE to docker run command line.
lsan needs ptrace and by default docker denies it.

@mikea
Copy link
Contributor Author

mikea commented Oct 12, 2016

I have verified that ClusterFuzz has detect_leaks=1 (@oliverchang). We'll keep detect_leaks=0 meanwhile in docker images.

lsan issue also filed: google/sanitizers#728

@kcc
Copy link
Contributor

kcc commented Dec 3, 2016

Could you please double-check again?
We haven't reported a single leak yet. This is very, very strange.

@inferno-chromium
Copy link
Collaborator

It is explicitly disabled in all job types. Oliver might know why. We can turn it on easily, we should just make sure it does not cause startup crashes, might cause some noise with fixed testcases. But CF should blacklist them automatically over time.

@oliverchang
Copy link
Collaborator

I just enabled this after doing some quick tests. Let's see if we get any reports tomorrow morning. Did something in LSan change recently? Last I tried (>1 month ago) this didn't work on our bots.

@kcc
Copy link
Contributor

kcc commented Dec 6, 2016

I don't remember any changes in LSan.
What didn't work?

@inferno-chromium
Copy link
Collaborator

No, changes in LSan. Just that we had this disabled in ClusterFuz via a job type environment variable. I think this might be done due to overcaution since both asan and lsan are in same job type. On chromium, we had these in different job type. But now that we have well tested automatic blacklisting and deblacklisting, this will work smoothly. And we see new leaks, see https://clusterfuzz-external.appspot.com/v2/testcases?q=leak&showall=1

@kcc
Copy link
Contributor

kcc commented Dec 6, 2016

lovely leaks!
Two of them have short stack traces, most likely because some of
the deps are built w/o -fno-omit-frame-pointers.
In the long run we'll solve this by rebuilding the world (needed for msan too).
In short term, for those two, we'll just rerun manually with fast_unwind_on_malloc=0

@mikea
Copy link
Contributor Author

mikea commented Dec 6, 2016

Can CF use fast_unwind_on_malloc=0 for reproducer only?

@oliverchang
Copy link
Collaborator

Unfortunately that might break CF, since we expect the crash state to be the same/similar during fuzzing and running a testcase for reproducibility purposes.

@kcc
Copy link
Contributor

kcc commented Dec 13, 2016

can we make lsan work in the docker? (by enabling --cap-add SYS_PTRACE)
It's pretty confusing when leaks are not reported inside the docker but then are reported by CF (e.g. #168)

@kcc kcc reopened this Dec 13, 2016
@mikea
Copy link
Contributor Author

mikea commented Dec 13, 2016

Do you know an easy way to check from the shell if ptrace is available? I'd like it to fail gracefully.

@kcc
Copy link
Contributor

kcc commented Dec 13, 2016

Run a simple program with a leak under lsan :)
But why do you want to fail gracefully if what we need is to pass (to make lsan work)?

@mikea
Copy link
Contributor Author

mikea commented Dec 13, 2016

I can add a flag to the helper.py, it is trivial. But people who run it without helper.py manually will see lsan report and will be confused.

@kcc
Copy link
Contributor

kcc commented Dec 13, 2016

ok... then indeed just run a simple test with a leak and verify that the leak is reported.

@inferno-chromium
Copy link
Collaborator

Well it is working inside docker.

(ENV) aarya@aarya-linux2:/build/oss-fuzz$ python infra/helper.py run_fuzzer $PROJECT_NAME gnutls_x509_parser_fuzzer
Running: docker build --pull -t ossfuzz/libfuzzer-runner infra/base-images/libfuzzer-runner
Sending build context to Docker daemon 2.56 kB
Step 1 : FROM ossfuzz/base-runner
latest: Pulling from ossfuzz/base-runner
Digest: sha256:292e0c2da06869c6c9fc83b87d05327b064c55219eaf172084fa0f56ce35c2fc
Status: Image is up to date for ossfuzz/base-runner:latest
---> fb0b1a3b7bbd
Step 2 : MAINTAINER [email protected]
---> Using cache
---> c0d835c656a0
Step 3 : RUN apt-get install -y gdb zip
---> Using cache
---> df638e632437
Successfully built df638e632437
Running: docker run --rm -i -v /usr/local/google/home/aarya/build/oss-fuzz/build/out/gnutls:/out -e ASAN_OPTIONS=coverage=0,detect_leaks=1 -t ossfuzz/libfuzzer-runner run_fuzzer /out/gnutls_x509_parser_fuzzer
Using seed corpus: /out/gnutls_x509_parser_fuzzer_seed_corpus.zip
/out/gnutls_x509_parser_fuzzer /tmp/seed_corpus/
INFO: Seed: 1052878858
INFO: Loaded 0 modules (0 guards):
Loading corpus dir: /tmp/seed_corpus/
Loaded 1024/1504 files from /tmp/seed_corpus/
INFO: -max_len is not provided, using 8668
#0 READ units: 1504

=================================================================
==10==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 16 byte(s) in 1 object(s) allocated from:
#0 0x4d4f20 in calloc /src/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:72
#1 0x550ef8 in gnutls_subject_alt_names_init /src/gnutls/lib/x509/x509_ext.c:53:10
#2 0x528588 in print_altname /src/gnutls/lib/x509/output.c:683:8
#3 0x51e8b6 in print_extension /src/gnutls/lib/x509/output.c:1009:4
#4 0x521bb7 in print_extensions /src/gnutls/lib/x509/output.c:1153:3
#5 0x515adc in print_cert /src/gnutls/lib/x509/output.c:1504:3
#6 0x51299a in gnutls_x509_crt_print /src/gnutls/lib/x509/output.c:1903:3
#7 0x511c55 in LLVMFuzzerTestOneInput /src/gnutls_x509_parser_fuzzer.cc:40:15
#8 0xa7e7cd in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:536:13
#9 0xa7f4d4 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:488:3
#10 0xa9d6ea in fuzzer::Fuzzer::RunOne(std::__1::vector<unsigned char, std::__1::allocator > const&) /src/libfuzzer/FuzzerInternal.h:119:41
#11 0xa7de8d in fuzzer::Fuzzer::ShuffleAndMinimize(std::__1::vector<std::__1::vector<unsigned char, std::__1::allocator >, std::__1::allocator<std::__1::vector<unsigned char, std::__1::allocator > > >) /src/libfuzzer/FuzzerLoop.cpp:467:30
#12 0xa1aaba in fuzzer::FuzzerDriver(int
, char***, int ()(unsigned char const, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:534:6
#13 0xa0dbe8 in main /src/libfuzzer/FuzzerMain.cpp:20:10
#14 0x7f29a269c82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)

SUMMARY: AddressSanitizer: 16 byte(s) leaked in 1 allocation(s).

INFO: a leak has been found in the initial corpus.

INFO: to ignore leaks on libFuzzer side use -detect_leaks=0.

MS: 0 ; base unit: 0000000000000000000000000000000000000000
artifact_prefix='./'; Test unit written to ./leak-20377d83e9b7aa6cc4b7f8a3fa2602e1fb22d947

diff --git a/infra/helper.py b/infra/helper.py
index 103797e..c08cb48 100755
--- a/infra/helper.py
+++ b/infra/helper.py
@@ -184,6 +184,7 @@ def run_fuzzer(run_args):
command = [
'docker', 'run', '--rm', '-i',
'-v', '%s:/out' % os.path.join(BUILD_DIR, 'out', args.project_name),

  •  '-e', 'ASAN_OPTIONS=coverage=0,detect_leaks=1',
     '-t', 'ossfuzz/libfuzzer-runner',
     'run_fuzzer',
     '/out/%s' % args.fuzzer_name,
    

@inferno-chromium
Copy link
Collaborator

Here are some options we can set in helper.py, these are set in ClusterFuzz.

ASAN_OPTIONS=handle_sigill=1:strict_string_check=1:strict_memcmp=1:detect_container_overflow=1:coverage=0:allocator_may_return_null=1:use_sigaltstack=1:allocator_release_to_os=1:detect_stack_use_after_return=1:alloc_dealloc_mismatch=0:detect_leaks=1:print_scariness=1:strip_path_prefix=/workspace/:max_uar_stack_size_log=16:handle_abort=1:check_malloc_usable_size=0:quarantine_size_mb=10:detect_odr_violation=0:symbolize=1:handle_segv=1:fast_unwind_on_fatal=0
UBSAN_OPTIONS=print_stacktrace=1:symbolize=1:halt_on_error=1:print_summary=1
MSAN_OPTIONS= don't see anything interesting other than symbolize=1:print_stats=1

mikea pushed a commit that referenced this issue Dec 21, 2016
I'm finding that with e.g.

python infra/helper.py build_fuzzers libpng

all builds fail for me with...

configure:3443: checking whether we are cross compiling
configure:3451: clang -o conftest -g -fsanitize=address -fsanitize-coverage=edge,indirect-calls,8bit-counters   conftest.c  >&5
configure:3455: $? = 0
configure:3462: ./conftest
==1014==LeakSanitizer has encountered a fatal error.
==1014==HINT: For debugging, try setting environment variable LSAN_OPTIONS=verbosity=1:log_threads=1
==1014==HINT: LeakSanitizer does not work under ptrace (strace, gdb, etc)
configure:3466: $? = 1
configure:3473: error: in `/src/libpng':
configure:3475: error: cannot run C compiled programs.

with the defaults of...
CC=clang
CXX=clang++
CFLAGS=-g -fsanitize=address -fsanitize-coverage=edge,indirect-calls,8bit-counters
CXXFLAGS=-g -fsanitize=address -fsanitize-coverage=edge,indirect-calls,8bit-counters -stdlib=libc++

but adding --cap-add SYS_PTRACE makes it work
@mikea mikea closed this as completed in d756773 Dec 28, 2016
bshastry pushed a commit to bshastry/oss-fuzz that referenced this issue Apr 27, 2019
Minor change to bug fix just for clarity
mhlakhani added a commit to mhlakhani/oss-fuzz that referenced this issue Sep 25, 2019
The corresponding github issue has more detail on the problem.

This code is not in any meaningful state to be committed -- it contains a bunch of hacks I had to make to get the binary to build statically -- libunwind is linked in (via folly), and I had to make changes to include liblzma as well (which libunwind depends on) as well as fix some other unrelated cmake issues.

Reproduction instructions below.

First, build it with `python infra/helper.py build_fuzzers --sanitizer address proxygen`
Then, check the build (it will pass): `python infra/helper.py check_build proxygen`
Then, run the fuzzer: `python infra/helper.py run_fuzzer proxygen ProxygenHTTP1xFuzzer`

It will fail in about ~30 seconds with the below trace. If the fuzzer goes down another path, I've had it reproduce easily by pulling up the shell, running `base64 -d`, pushing that input to a file, and then running the fuzzer directly on that file.

```
terminating with uncaught exception of type folly::ConversionError: Non-digit character found: "OPY"
AddressSanitizer:DEADLYSIGNAL
=================================================================
==11==ERROR: AddressSanitizer: ABRT on unknown address 0x00000000000b (pc 0x7fc166eb7428 bp 0x000000000001 sp 0x7ffcff0a6c78 T0)
SCARINESS: 10 (signal)
    #0 0x7fc166eb7427 in gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x35427)
    google#1 0x7fc166eb9029 in abort (/lib/x86_64-linux-gnu/libc.so.6+0x37029)
    google#2 0x9ab7fa in abort_message (/out/ProxygenHTTP1xFuzzer+0x9ab7fa)
    google#3 0x9b009d in demangling_terminate_handler() (/out/ProxygenHTTP1xFuzzer+0x9b009d)
    google#4 0x9ab282 in std::__terminate(void (*)()) (/out/ProxygenHTTP1xFuzzer+0x9ab282)
    google#5 0x9adebd in __cxxabiv1::call_terminate(bool, _Unwind_Exception*) (/out/ProxygenHTTP1xFuzzer+0x9adebd)
    google#6 0x9ade60 in __cxxabiv1::scan_eh_tab(__cxxabiv1::(anonymous namespace)::scan_results&, _Unwind_Action, bool, _Unwind_Exception*, _Unwind_Context*) (/out/ProxygenHTTP1xFuzzer+0x9ade60)
    google#7 0x9ad5c6 in __gxx_personality_v0 (/out/ProxygenHTTP1xFuzzer+0x9ad5c6)
    google#8 0x7fc16725c262 in _Unwind_RaiseException (/lib/x86_64-linux-gnu/libgcc_s.so.1+0x10262)
    google#9 0x9acfd6 in __cxa_throw (/out/ProxygenHTTP1xFuzzer+0x9acfd6)
    google#10 0x5cedab in void folly::throw_exception<folly::ConversionError>(folly::ConversionError&&) /src/proxygen/proxygen/_build/deps/include/folly/lang/Exception.h:36:3
    google#11 0x5eea03 in _ZZN5folly2toItEENSt3__19enable_ifIXntsr3std7is_sameINS_5RangeIPKcEET_EE5valueES7_E4typeES6_ENKUlNS_14ConversionCodeEE_clESA_ /src/proxygen/proxygen/_build/deps/include/folly/Conv.h:1581:26
    google#12 0x5eea03 in _ZN5folly15expected_detail30expected_detail_ExpectedHelper14ExpectedHelper12thenOrThrow_IRNS0_15ExpectedStorageINS_5RangeIPKcEENS_14ConversionCodeELNS0_11StorageTypeE1EEENS_6detail18CheckTrailingSpaceEZNS_2toItEENSt3__19enable_ifIXntsr3std7is_sameIS8_T_EE5valueESI_E4typeES8_EUlS9_E_NS_8ExpectedINS_4UnitES9_EEvLb0ELi0EEET2_OSI_OT0_OT1_ /src/proxygen/proxygen/_build/deps/include/folly/Expected.h:610:5
    google#13 0x5ed846 in _ZNR5folly8ExpectedINS_5RangeIPKcEENS_14ConversionCodeEE11thenOrThrowINS_6detail18CheckTrailingSpaceEZNS_2toItEENSt3__19enable_ifIXntsr3std7is_sameIS4_T_EE5valueESD_E4typeES4_EUlS5_E_EEDTclclsr3stdE7declvalISD_EEclL_ZNSB_7declvalIRS4_EEDTclsr3std3__1E9__declvalISD_ELi0EEEvEEEEOSD_OT0_ /src/proxygen/proxygen/_build/deps/include/folly/Expected.h:1226:16
    google#14 0x5ed846 in _ZN5folly2toItEENSt3__19enable_ifIXntsr3std7is_sameINS_5RangeIPKcEET_EE5valueES7_E4typeES6_ /src/proxygen/proxygen/_build/deps/include/folly/Conv.h:1579:8
    google#15 0x5ed445 in proxygen::ParseURL::parseAuthority() /src/proxygen/proxygen/lib/utils/ParseURL.cpp:155:15
    google#16 0x5ec5e9 in proxygen::ParseURL::parseNonFully() /src/proxygen/proxygen/lib/utils/ParseURL.cpp:140:8
    google#17 0x5ea87a in proxygen::ParseURL::parse() /src/proxygen/proxygen/lib/utils/ParseURL.cpp:96:5
    google#18 0x59a99c in proxygen::ParseURL::init(folly::Range<char const*>) /src/proxygen/proxygen/lib/utils/ParseURL.h:34:5
    google#19 0x58add1 in proxygen::ParseURL::ParseURL(folly::Range<char const*>) /src/proxygen/proxygen/lib/utils/ParseURL.h:28:5
    google#20 0x58add1 in proxygen::ParseURL proxygen::HTTPMessage::setURL<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >&&) /src/proxygen/proxygen/lib/http/HTTPMessage.h:202:14
    google#21 0x5795f0 in proxygen::HTTP1xCodec::onHeadersComplete(unsigned long) /src/proxygen/proxygen/lib/http/codec/HTTP1xCodec.cpp:976:31
    google#22 0x58e2a3 in proxygen::HTTP1xCodec::onHeadersCompleteCB(proxygen::http_parser*, char const*, unsigned long) /src/proxygen/proxygen/lib/http/codec/HTTP1xCodec.cpp:1315:19
    google#23 0x5f2222 in proxygen::http_parser_execute(proxygen::http_parser*, proxygen::http_parser_settings const*, char const*, unsigned long) /src/proxygen/proxygen/external/http_parser/http_parser_cpp.cpp:1868:17
    google#24 0x577783 in proxygen::HTTP1xCodec::onIngress(folly::IOBuf const&) /src/proxygen/proxygen/lib/http/codec/HTTP1xCodec.cpp:200:26
    google#25 0x55b728 in unsigned long proxygen::parse<proxygen::HTTP1xCodec>(proxygen::HTTP1xCodec*, unsigned char const*, unsigned int, int, std::__1::function<bool ()>) /src/proxygen/proxygen/lib/http/codec/test/TestUtils.h:57:23
    google#26 0x55a6ef in LLVMFuzzerTestOneInput /src/proxygen/proxygen/fuzzers/ProxygenHTTP1xFuzzer.cpp:23:3
    google#27 0x460771 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm/projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:554:15
    google#28 0x45fe95 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /src/llvm/projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:470:3
    google#29 0x462247 in fuzzer::Fuzzer::MutateAndTestOne() /src/llvm/projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:696:19
    google#30 0x462fe5 in fuzzer::Fuzzer::Loop(std::Fuzzer::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /src/llvm/projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:832:5
    google#31 0x450dd8 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm/projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:825:6
    google#32 0x47b442 in main /src/llvm/projects/compiler-rt/lib/fuzzer/FuzzerMain.cpp:19:10
    google#33 0x7fc166ea282f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    google#34 0x424468 in _start (/out/ProxygenHTTP1xFuzzer+0x424468)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: ABRT (/lib/x86_64-linux-gnu/libc.so.6+0x35427) in gsignal
==11==ABORTING
MS: 3 CrossOver-ChangeBit-EraseBytes-; base unit: 467e3fbf38770044dea566169b84c60cb269c89a
0x43,0x4f,0x50,0x59,0x20,0x43,0x3a,0x4f,0x50,0x59,0x2f,0x4f,0xff,0xa,0x43,0x4f,0x50,0x59,0x20,0x2f,0x4f,0xff,0xa,0x43,0x4f,0x50,0x59,0x20,0x2f,0x6f,0x20,0xff,0x50,0x59,0x0,0x43,0xcf,0x50,0x59,0xff,0x4f,0x50,0x33,
COPY C:OPY/O\xff\x0aCOPY /O\xff\x0aCOPY /o \xffPY\x00C\xcfPY\xffOP3
artifact_prefix='./'; Test unit written to ./crash-2cd12847d55ebf08ec2eaee4e814c52e545e7f92
Base64: Q09QWSBDOk9QWS9P/wpDT1BZIC9P/wpDT1BZIC9vIP9QWQBDz1BZ/09QMw==
```

This seems wrong to me since the code is inside a try/catch block: https://github.com/facebook/proxygen/blob/master/proxygen/lib/utils/ParseURL.cpp#L159-L164

I can confirm that the same input does not crash the fuzzer in the version being built on oss-fuzz trunk (and indeed it would have also reported this as a test-case by now given it's been running over a day)
jonathanmetzman added a commit that referenced this issue Dec 6, 2022
cc @oliverchang @alan32liu after #9100 and #8448

After compiling locally, I can see that
`./SystemSan ./target_dns -dict=vuln.dict`
crashes in a few seconds with
```
===BUG DETECTED: Arbitrary domain name resolution===
===Domain resolved: .f.z===
===DNS request type: 0, class: 256===
==315== ERROR: libFuzzer: deadly signal
    #0 0x539131 in __sanitizer_print_stack_trace /src/llvm-project/compiler-rt/lib/asan/asan_stack.cpp:87:3
    #1 0x457c48 in fuzzer::PrintStackTrace() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:5
    #2 0x43c923 in fuzzer::Fuzzer::CrashCallback() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:233:3
    #3 0x7fa57940041f  (/lib/x86_64-linux-gnu/libpthread.so.0+0x1441f) (BuildId: 7b4536f41cdaa5888408e82d0836e33dcf436466)
    #4 0x7fa5793ff7db in send (/lib/x86_64-linux-gnu/libpthread.so.0+0x137db) (BuildId: 7b4536f41cdaa5888408e82d0836e33dcf436466)
    #5 0x503ba4 in __interceptor_send /src/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:6802:17
    #6 0x7fa578abf462  (/lib/x86_64-linux-gnu/libresolv.so.2+0xb462) (BuildId: 4519041bde5b859c55798ac0745b0b6199cb7d94)
    #7 0x7fa578abbc43 in __res_context_query (/lib/x86_64-linux-gnu/libresolv.so.2+0x7c43) (BuildId: 4519041bde5b859c55798ac0745b0b6199cb7d94)
    #8 0x7fa578abc8ed in __res_context_search (/lib/x86_64-linux-gnu/libresolv.so.2+0x88ed) (BuildId: 4519041bde5b859c55798ac0745b0b6199cb7d94)
    #9 0x7fa578ad2cc1  (/lib/x86_64-linux-gnu/libnss_dns.so.2+0x2cc1) (BuildId: 3fac4ec397ba8e8938fe298f103113f315465130)
    #10 0x7fa578ad2e8b in _nss_dns_gethostbyname3_r (/lib/x86_64-linux-gnu/libnss_dns.so.2+0x2e8b) (BuildId: 3fac4ec397ba8e8938fe298f103113f315465130)
    #11 0x7fa578ad2f41 in _nss_dns_gethostbyname2_r (/lib/x86_64-linux-gnu/libnss_dns.so.2+0x2f41) (BuildId: 3fac4ec397ba8e8938fe298f103113f315465130)
    #12 0x7fa5792fdc9d in gethostbyname2_r (/lib/x86_64-linux-gnu/libc.so.6+0x130c9d) (BuildId: 1878e6b475720c7c51969e69ab2d276fae6d1dee)
    #13 0x7fa5792d179e  (/lib/x86_64-linux-gnu/libc.so.6+0x10479e) (BuildId: 1878e6b475720c7c51969e69ab2d276fae6d1dee)
    #14 0x7fa5792d2f58 in getaddrinfo (/lib/x86_64-linux-gnu/libc.so.6+0x105f58) (BuildId: 1878e6b475720c7c51969e69ab2d276fae6d1dee)
    #15 0x4d93ac in getaddrinfo /src/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:2667:13
    #16 0x56c8d9 in LLVMFuzzerTestOneInput /out/SystemSan/target_dns.cpp:35:11
    #17 0x43dec3 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:611:15
    #18 0x43d6aa in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool, bool*) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:514:3
    #19 0x43ed79 in fuzzer::Fuzzer::MutateAndTestOne() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:757:19
    #20 0x43fa45 in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector<fuzzer::SizedFile, std::__Fuzzer::allocator<fuzzer::SizedFile> >&) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:895:5
    #21 0x42edaf in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:912:6
    #22 0x458402 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
    #23 0x7fa5791f1082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId: 1878e6b475720c7c51969e69ab2d276fae6d1dee)
    #24 0x41f7ed in _start (/out/SystemSan/target_dns+0x41f7ed)

NOTE: libFuzzer has rudimentary signal handlers.
      Combine libFuzzer with AddressSanitizer or similar for better crash reports.
SUMMARY: libFuzzer: deadly signal
MS: 2 CrossOver-ManualDict- DE: "f.z"-; base unit: ac3478d69a3c81fa62e60f5c3696165a4e5e6ac4
0x66,0x2e,0x7a,
f.z
artifact_prefix='./'; Test unit written to ./crash-926813b2d6adde373f96a10594a5314951588384
Base64: Zi56
```

You can also try
```
echo -n f.z > toto
./SystemSan ./target_dns toto  
```

Co-authored-by: Oliver Chang <[email protected]>
Co-authored-by: jonathanmetzman <[email protected]>
eamonnmcmanus pushed a commit to eamonnmcmanus/oss-fuzz that referenced this issue Mar 15, 2023
cc @oliverchang @alan32liu after google#9100 and google#8448

After compiling locally, I can see that
`./SystemSan ./target_dns -dict=vuln.dict`
crashes in a few seconds with
```
===BUG DETECTED: Arbitrary domain name resolution===
===Domain resolved: .f.z===
===DNS request type: 0, class: 256===
==315== ERROR: libFuzzer: deadly signal
    #0 0x539131 in __sanitizer_print_stack_trace /src/llvm-project/compiler-rt/lib/asan/asan_stack.cpp:87:3
    google#1 0x457c48 in fuzzer::PrintStackTrace() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:5
    google#2 0x43c923 in fuzzer::Fuzzer::CrashCallback() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:233:3
    google#3 0x7fa57940041f  (/lib/x86_64-linux-gnu/libpthread.so.0+0x1441f) (BuildId: 7b4536f41cdaa5888408e82d0836e33dcf436466)
    google#4 0x7fa5793ff7db in send (/lib/x86_64-linux-gnu/libpthread.so.0+0x137db) (BuildId: 7b4536f41cdaa5888408e82d0836e33dcf436466)
    google#5 0x503ba4 in __interceptor_send /src/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:6802:17
    google#6 0x7fa578abf462  (/lib/x86_64-linux-gnu/libresolv.so.2+0xb462) (BuildId: 4519041bde5b859c55798ac0745b0b6199cb7d94)
    google#7 0x7fa578abbc43 in __res_context_query (/lib/x86_64-linux-gnu/libresolv.so.2+0x7c43) (BuildId: 4519041bde5b859c55798ac0745b0b6199cb7d94)
    google#8 0x7fa578abc8ed in __res_context_search (/lib/x86_64-linux-gnu/libresolv.so.2+0x88ed) (BuildId: 4519041bde5b859c55798ac0745b0b6199cb7d94)
    google#9 0x7fa578ad2cc1  (/lib/x86_64-linux-gnu/libnss_dns.so.2+0x2cc1) (BuildId: 3fac4ec397ba8e8938fe298f103113f315465130)
    google#10 0x7fa578ad2e8b in _nss_dns_gethostbyname3_r (/lib/x86_64-linux-gnu/libnss_dns.so.2+0x2e8b) (BuildId: 3fac4ec397ba8e8938fe298f103113f315465130)
    google#11 0x7fa578ad2f41 in _nss_dns_gethostbyname2_r (/lib/x86_64-linux-gnu/libnss_dns.so.2+0x2f41) (BuildId: 3fac4ec397ba8e8938fe298f103113f315465130)
    google#12 0x7fa5792fdc9d in gethostbyname2_r (/lib/x86_64-linux-gnu/libc.so.6+0x130c9d) (BuildId: 1878e6b475720c7c51969e69ab2d276fae6d1dee)
    google#13 0x7fa5792d179e  (/lib/x86_64-linux-gnu/libc.so.6+0x10479e) (BuildId: 1878e6b475720c7c51969e69ab2d276fae6d1dee)
    google#14 0x7fa5792d2f58 in getaddrinfo (/lib/x86_64-linux-gnu/libc.so.6+0x105f58) (BuildId: 1878e6b475720c7c51969e69ab2d276fae6d1dee)
    google#15 0x4d93ac in getaddrinfo /src/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:2667:13
    google#16 0x56c8d9 in LLVMFuzzerTestOneInput /out/SystemSan/target_dns.cpp:35:11
    google#17 0x43dec3 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:611:15
    google#18 0x43d6aa in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool, bool*) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:514:3
    google#19 0x43ed79 in fuzzer::Fuzzer::MutateAndTestOne() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:757:19
    google#20 0x43fa45 in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector<fuzzer::SizedFile, std::__Fuzzer::allocator<fuzzer::SizedFile> >&) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:895:5
    google#21 0x42edaf in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:912:6
    google#22 0x458402 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
    google#23 0x7fa5791f1082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId: 1878e6b475720c7c51969e69ab2d276fae6d1dee)
    google#24 0x41f7ed in _start (/out/SystemSan/target_dns+0x41f7ed)

NOTE: libFuzzer has rudimentary signal handlers.
      Combine libFuzzer with AddressSanitizer or similar for better crash reports.
SUMMARY: libFuzzer: deadly signal
MS: 2 CrossOver-ManualDict- DE: "f.z"-; base unit: ac3478d69a3c81fa62e60f5c3696165a4e5e6ac4
0x66,0x2e,0x7a,
f.z
artifact_prefix='./'; Test unit written to ./crash-926813b2d6adde373f96a10594a5314951588384
Base64: Zi56
```

You can also try
```
echo -n f.z > toto
./SystemSan ./target_dns toto  
```

Co-authored-by: Oliver Chang <[email protected]>
Co-authored-by: jonathanmetzman <[email protected]>
DavidKorczynski pushed a commit that referenced this issue Apr 5, 2023
We've still got an issue with crashes on the urllib3 requests test that
uses the mock HTTP server.

Fix #9958 to handle port mapping errors didn't resolve it.

I got a feeling there's an ordering issue. Looking at the error logs
[https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=56500#c2](https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=56500#c2)
there appears to be an issue where we're throwing exceptions before the
coverage completes.

```
=== Uncaught Python exception: ===
--
  | MaxRetryError: HTTPConnectionPool(host='localhost', port=8011): Max retries exceeded with url: / (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f4cdf33d1f0>: Failed to establish a new connection: [Errno 101] Network is unreachable'))
  | Traceback (most recent call last):
  | File "fuzz_requests.py", line 109, in TestOneInput
  | File "urllib3/_request_methods.py", line 118, in request
  | File "urllib3/_request_methods.py", line 217, in request_encode_body
  | File "urllib3/poolmanager.py", line 433, in urlopen
  | File "urllib3/connectionpool.py", line 874, in urlopen
  | File "urllib3/connectionpool.py", line 874, in urlopen
  | File "urllib3/connectionpool.py", line 874, in urlopen
  | File "urllib3/connectionpool.py", line 844, in urlopen
  | File "urllib3/util/retry.py", line 505, in increment
  | MaxRetryError: HTTPConnectionPool(host='localhost', port=8011): Max retries exceeded with url: / (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f4cdf33d1f0>: Failed to establish a new connection: [Errno 101] Network is unreachable'))
  |  
  | INFO: Instrumenting 3854 functions...
  | INFO: Instrumentation complete.
  | ==10674== ERROR: libFuzzer: fuzz target exited
  | #0 0x7f4ce0bac694 in __sanitizer_print_stack_trace /src/llvm-project/compiler-rt/lib/ubsan/ubsan_diag_standalone.cpp:31:3
  | #1 0x7f4ce0b2df48 in fuzzer::PrintStackTrace() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:5
  | #2 0x7f4ce0b12cdc in fuzzer::Fuzzer::ExitCallback() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:250:3
  | #3 0x7f4ce09068a6 in __run_exit_handlers /build/glibc-SzIz7B/glibc-2.31/stdlib/exit.c:108:8
  | #4 0x7f4ce0906a5f in exit /build/glibc-SzIz7B/glibc-2.31/stdlib/exit.c:139:3
  | #5 0x7f4ce03b2c78 in libpython3.8.so.1.0
  | #6 0x7f4ce03b76cf in libpython3.8.so.1.0
  | #7 0x403ad2 in fuzz_requests.pkg
  | #8 0x403e67 in fuzz_requests.pkg
  | #9 0x7f4ce08e4082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/libc-start.c:308:16
  | #10 0x40249d in fuzz_requests.pkg
  |  
  | SUMMARY: libFuzzer: fuzz target exited
```

This is an attempted fix inspired by the requests
[fuzz_server.py](https://github.com/google/oss-fuzz/blob/master/projects/requests/fuzz_server.py)
where the lifecycle of the test thread is managed within the server.
Since the web server is created at the start of `TestOneInput` I don't
expect there to be any timing issues or thread initialisation issues.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants