[toml-rs] initial integration

[evverx]

I'm trying to figure out how cargo fuzz is integrated into OSS-Fuzz. The build script points to my fork: https://github.com/evverx/toml-rs/commits/fuzz

The fuzz target has found a stack-overflow locally (as far as I can tell, it's the same stack overflow as the one reported in toml-rs/toml-rs#428) so it seems to be working more or less

@alexcrichton I'd appreciate it if you could take a look at the fuzzer. It's currently at toml-rs/toml-rs#430

[evverx]

What's weird though is that when I run cargo fuzz manually I get more or less helpful ASan reports that look like

fuzz/target/x86_64-unknown-linux-gnu/release/fuzz_from_to_string: Running 1 inputs 1 time(s) each.
Running: /home/vagrant/oss-fuzz/crash-550d3b764ef9f9c5cc5c17debbe7d409fe8c6acf
AddressSanitizer:DEADLYSIGNAL
=================================================================
==176445==ERROR: AddressSanitizer: stack-overflow on address 0x7ffe7fbc0be8 (pc 0x557cf91b1599 bp 0x7ffe7fbc1430 sp 0x7ffe7fbc0bf0 T0)
    #0 0x557cf91b1599 in __asan_memcpy /rustc/llvm/src/llvm-project/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:22:3
    #1 0x557cf93cc3ae in toml::tokens::Tokenizer::next::hf6b8c8d030b31dfa (/home/vagrant/RUST/toml-rs/fuzz/target/x86_64-unknown-linux-gnu/release/fuzz_from_to_string+0x3443ae)
    #2 0x557cf93cd1ff in toml::tokens::Tokenizer::eat_spanned::h9837d6eda53f0117 (/home/vagrant/RUST/toml-rs/fuzz/target/x86_64-unknown-linux-gnu/release/fuzz_from_to_string+0x3451ff)
    #3 0x557cf93bcecf in toml::de::Deserializer::array::_$u7b$$u7b$closure$u7d$$u7d$::h2b043825ebdefbfc (/home/vagrant/RUST/toml-rs/fuzz/target/x86_64-unknown-linux-gnu/release/fuzz_from_to_string+0x334ecf)
...
SUMMARY: AddressSanitizer: stack-overflow /rustc/llvm/src/llvm-project/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:22:3 in __asan_memcpy
==176445==ABORTING
────────────────────────────────────────────────────────────────────────────────

but with ./infra/helper.py I get

/out/fuzz_from_to_string: Running 1 inputs 100 time(s) each.
Running: /testcase
bash: line 1:    12 Segmentation fault      (core dumped) /out/fuzz_from_to_string -rss_limit_mb=2560 -timeout=25 -runs=100 /testcase -dict=fuzz_from_to_string.dict < /dev/null

I wonder if this is a known issue

[evverx]

I've just opened toml-rs/toml-rs#430 to make it easier to review the fuzz target.

[evverx]

The fuzzer built with ./infra/helper.py segfaults without the backtrace outside the docker container too so it doesn't seem to be related to docker containers. I'll try to rebuild the base image builder without CUSTOM_LIBFUZZER_PATH and CUSTOM_LIBFUZZER_STD_CXX to see whether it helps: #5867 (comment)

@inferno-chromium I wonder what ClusterFuzz does when fuzz targets crash like that. Would it report issues without backtraces?

[alexcrichton]

Thanks for the offer here! Unfortunately though I don't have a ton of time to maintain and fix fuzz bugs found. I suspect that they're probably somewhat easy-ish to fix but I don't have the time to track them all down just yet (and I suspect there's at least a few others lurking). If someone else is willing to help fix these issues though I would be fine adding this to oss-fuzz!

[evverx]

As far as know toml was integrated into another crate and it's already fuzzed. Closing.