I'd like to know what Googlers (and Mozillians) think of this.

There are currently two Firefox projects here: qcms and spidermonkey. Both build stand-alone and are also useful separate from Firefox. Firefox core does however have many more potential targets. I'll give a simple example: the FTP LIST parser. Please take a look.

For such targets Firefox has a native fuzzing interface, which is integrated into its normal build system, and produces a binary that can be run with the normal libFuzzer flags. (ASAN-only currently.) Quite similar to how spidermonkey seems to be integrated here right now.

Is this still within the scope of oss-fuzz?

@jonathanmetzman @lszekeres @inferno-chromium

The following are variations on how you can run afl++ effectively.

1. building afl++

git clone https://github.com/AFLplusplus/AFLplusplus afl++
cd afl++
checkout stable
make all
make -C llvm_mode
make -C examples/aflpp_driver

The last entry builds the libafl driver (see https://github.com/google/fuzzbench/blob/master/fuzzers/aflplusplus/builder.Dockerfile)

2. building targets Just use afl-clang-fast afl-clang-lto is a full step better (faster, auto dictionary) plus has a high impact on build time. Plain, or better with two useful options:

AFL_LLVM_CMPLOG=1     <= cmplog/redqueen, highly effective., not compatible with afl spinoffs
AFL_LLVM_LAF_ALL=1     <= highly improved laf-intel (floats, non-literal string support, etc.), compatible with afl spinoffs

Note that the binary comparability with afl and spin-offs are limited, as afl++ support variable map sizes - means: afl-fuzz and the target choose the correct size and have a non-colliding coverage. So far some targets the map will be 15k entries, and these are no problem. For a few large targets it can be > 64k and then these binaries cannot be used with others.

Note that for cmplog you are faster if you compile one version with cmplog and one without. the cmplog version is passed with the -c parameter to afl-fuzz. However if you do not care to loose a bit of speed, then you can use just a cmplog compiled one for both.

3. running targets The normal havoc mode is improved on afl and better than MOpt, and if it has a cycle without finds then it addionally activates MOpt. so your choices are:

  -L 0   <- MOpt only
  -L -1 <- start with mixed mode
 nothing  <- mixed mode is turned on after a cycle without finds
  AFL_EXPAND_HAVOC_NOW=1  <- dont wait for a cycle without finds to enable advanced havoc mode

And then you can select a schedule. we have 9 schedules and the best are: seek, rare, explore (the default). (-p schedule).

as you are fuzzing with an existing and growing corpus I highly recommend to use cmplog and laf-intel, use AFL_EXPAND_HAVOC_NOW and -p rare or -p seek. These options are the more effective ones to find new paths.

If you have further questions - just put them here.

Let's use this issue to maintain a list of projects that we want to see on oss-fuzz. Volunteers welcome!

• [x] binutils, e.g. cplus_demangle (seen fuzzable bugs in the past)
• [x] more fuzz targets from LLVM, we currently have only llvm_libcxxabi
• [ ] libstdc++ regex (e.g. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79539)
• [x] libexif
• [x] PCRE (we have PCRE2, but not PCRE)
• [x] python (https://bugs.python.org/issue29505)
• [x] gstreamer (https://lwn.net/Articles/708196/ and also https://github.com/google/oss-fuzz/issues/93)
• [x] mysql
• [x] http://www.gfwx.org/
• [x] http://www.libtiff.org/
• [x] https://sourceforge.net/projects/giflib/
• [x] https://github.com/jrmuizel/qcms/
• [x] imagemagick @dlemstra (https://github.com/google/oss-fuzz/issues/430)
• [x] ~~graphviz @emdenrg (https://github.com/google/oss-fuzz/issues/182)~~ (upstream not interested)
• [x] gstreamer @bilboed (https://github.com/google/oss-fuzz/issues/93)
• [ ] vim/neovim @dpelle (https://github.com/google/oss-fuzz/issues/96)
• [ ] s2n @raycoll, @alexw91, @colmmacc (https://github.com/google/oss-fuzz/issues/238)
• [ ] libelf, libdwarf (https://github.com/google/oss-fuzz/issues/64) (add to this list instead of creating a new comment)
• [ ] more/better fuzzing for ICU https://github.com/google/oss-fuzz/tree/master/projects/icu
• [x] apache httpd
• [x] https://xerces.apache.org/xerces-c/
• [x] https://github.com/google/piex
• [x] libidn2
• [x] libzip
• [x] dovecot
• [x] Node.js
• [ ] tcpdump
• [ ] bluez
• [x] cairo
• [ ] coreboot
• [x] dbus
• [ ] dhcpcd
• [ ] dtc (device tree compiler)
• [ ] laptop-mode-tools
• [ ] libcamera
• [ ] libevdev
• [ ] libiio
• [ ] libpciaccess
• [ ] modemmanager
• [ ] xf86-input-synaptics
• [x] vlc
• [x] php-src
• [x] bind9
• [ ] projects from Cloud Native Computing Foundation(https://www.cncf.io/projects/)

(consider this as a work-in-progress design doc, it will be periodically updated) EDIT 2019-06-20

Data Flow Trace

The Data Flow Trace (DFT) tells the fuzzing engine which bytes of a given input affect which comparison instructions. In the following example, if an input reaches CMP1, DFT will tell us that CMP1 is affected by data[55], data[66] and data[77].

int LLVMFuzzerTestOneInput(const unsigned char *data, size_t size) {
  int x = SomeFunctionOf(data[55], data[66]);
  ...
  if(x == data[77]) // CMP1
    ...
}

DataFlowSanitizer (DFSan) allows us to collect byte-precise DFT, typically at the cost of several executions of a given input.

Collecting the DFT

In order to collect the DFT the target needs to be compiled with DFSan+SanitizerCoverage and linked with a special driver. The exact details are here.

Then the DFT needs to be collected for the entire seed corpus (see the example below). This will create a new directory with the DFT, which then needs to be compressed and stored on the network disk.

Using the DFT

The libFuzzer runners will use the DFT with some probability. If DFT is chosen for a particular run, the DFT directory is downloaded from the network disk and uncompressed on the local runner. Note that the DFT from the previous fuzzing iteration remains mostly usable, and so we do not need to synchronize the DFT collection and the use.

libFuzzer will need to be run with two extra flags (other flags are as usual):

• -data_flow_trace=<DFT_DIR>: this simply instructs libFuzzer to load the DFT from <DFT_DIR>.
• -focus_function=auto: this instructs libFuzzer to choose a focus function based on the DFT.

Alternatively, DFT could be collected by libFuzzer on the fly with -collect_data_flow=./dft-binary -fork=1, see below.

Example

This command sequence shows how to apply DFT-based fuzzing to the OnlySomeBytesTest.cpp puzzle.

#!/bin/bash
LLVM=$HOME/llvm-project
RT=$LLVM/compiler-rt
# Build the regular fuzzer binary.
clang -g -O0 -fsanitize=fuzzer $RT/test/fuzzer/OnlySomeBytesTest.cpp -o fuzzer-lf
# Build the DFT binary.
clang -c  -fsanitize=dataflow $RT/lib/fuzzer/dataflow/DataFlow.cpp
clang -c -fPIC $RT/lib/fuzzer/dataflow/DataFlowCallbacks.cpp
clang -g -fsanitize=dataflow -fsanitize-coverage=trace-pc-guard,pc-table,bb,trace-cmp  \
    $RT/test/fuzzer/OnlySomeBytesTest.cpp DataFlow*.o -o fuzzer-dft

# create the corpus
rm -rf CORPUS && mkdir CORPUS
(echo -n ABC; for((i=0;i<4093;i++)) ; do echo -n x; done) > CORPUS/seed
./fuzzer-lf CORPUS/ -use_value_profile=1 -runs=1000000 # Very unlikely to find the bug.

# create_dft()
rm -rf DFT && ./fuzzer-lf -collect_data_flow=./fuzzer-dft -data_flow_trace=DFT CORPUS

# Use DFT. This should find the bug almost instantly.
rm -rf C2; mkdir C2
./fuzzer-lf C2 CORPUS/ -use_value_profile=1 -data_flow_trace=DFT \
  -focus_function=auto -jobs=20 -artifact_prefix=C2/

# Or, much simpler with fork mode which will collect DFT itself:
./fuzzer-lf -use_value_profile=1 -collect_data_flow=./fuzzer-dft -fork=1

The only case I've verified where this happens is jsonnet. However, it looks like the same issue occurs with freeimage (load_from_memory_fuzzer), libsass (data_context_fuzzer), and opencv (imdecode_fuzzer)

To reproduce, download my patch and run these commands:

git apply jsonnet.txt
python infra/helper.py build_fuzzers jsonnet
python infra/helper.py check_build jsonnet
...
AddressSanitizer:DEADLYSIGNAL
=================================================================
==36==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f236d5b6d10 bp 0x00000090605b sp 0x7ffd7f950d68 T0)
==36==The signal is caused by a READ memory access.
==36==Hint: address points to the zero page.
SCARINESS: 10 (null-deref)
ERROR: 100% of fuzz targets seem to be broken. See the list above for a detailed information.
Check build failed

This is a stacktrace that I captured slightly before the crash occurs.

#0  __asan_handle_no_return () at /src/llvm/projects/compiler-rt/lib/asan/asan_rtl.cc:598
#1  0x00000000005f7084 in (anonymous namespace)::Parser::parseTerminalBracketsOrUnary (this=0x6110000000c0) at /src/jsonnet/core/parser.cpp:591
#2  0x00000000005e5321 in (anonymous namespace)::Parser::parse (this=0x7fffffffcec0, max_precedence=<optimized out>) at /src/jsonnet/core/parser.cpp:898
#3  0x00000000005e49f8 in jsonnet_parse (alloc=<optimized out>, tokens=...) at /src/jsonnet/core/parser.cpp:1093
#4  0x00000000005caed7 in jsonnet_evaluate_snippet_aux (vm=<optimized out>, filename=<optimized out>, snippet=<optimized out>, error=<optimized out>, kind=<optimized out>) at /src/jsonnet/core/libjsonnet.cpp:492
#5  0x00000000005ca76d in jsonnet_evaluate_snippet (vm=0x60f000000040, filename=0x89c900 <.str> "", snippet=0x7fffffffdaa1 "", error=0x7fffffffd9c0) at /src/jsonnet/core/libjsonnet.cpp:667
#6  0x00000000005bbcce in ConvertJsonnetToJson(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) () at convert_jsonnet_fuzzer.cc:24
#7  0x00000000005bc011 in LLVMFuzzerTestOneInput () at convert_jsonnet_fuzzer.cc:40
#8  0x00000000004c2f35 in ExecuteCallback () at /src/llvm/projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:529
#9  0x00000000004c4e54 in ReadAndExecuteSeedCorpora () at /src/llvm/projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:729
#10 0x00000000004c5426 in Loop () at /src/llvm/projects/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:779
#11 0x00000000004b437b in FuzzerDriver () at /src/llvm/projects/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:776
#12 0x00000000004de3d3 in main () at /src/llvm/projects/compiler-rt/lib/fuzzer/FuzzerMain.cpp:19

The crash does not occur when -lFuzzingEngine is used instead of -fsanitize=fuzzer

The source line (parser.cpp:591) causing the crash contains: throw StaticError(tok.location, "unexpected end of file.");

I think this crash has something to do with exceptions.

I have integrated CIFuzz with my project (libjpeg-turbo), but I cannot figure out how to make it test the actual code that is being passed to GitHub Actions. Because of https://github.com/google/oss-fuzz/blob/9f236c1c9c5929cf152f39312796d72acead175c/projects/libjpeg-turbo/Dockerfile#L19 the main branch of libjpeg-turbo is always built and tested. This can be confirmed in the GitHub Actions log files.

This log file is from fuzzing the dev branch, which should be v2.1.80, but CIFuzz is testing v2.1.4 from the main branch instead: https://github.com/libjpeg-turbo/libjpeg-turbo/runs/5518437997

This log file is from fuzzing the 2.0.x branch, which should be v2.0.7, but CIFuzz is testing v2.1.4 from the main branch instead: https://github.com/libjpeg-turbo/libjpeg-turbo/runs/5728485608

cc @inferno-chromium and @Dor1s Fixes #4637

This will work when https://github.com/rust-lang/rust/pull/79365 gets merged into rust nightly compiler and gets shipped into oss-fuzz docker images (or if you recompile rustc)

This is a draft PR. The right one will not use a custom patch for Suricata, but wait until https://github.com/OISF/suricata/pull/5595 is merged

Last, there is a question about the demangler As some project may have both C++ and Rust, I think that the demangler should be a custom one basically doing rustfilt | c++filt -n Do you have thoughts on that ?

We have the following error in the fuzz build: https://oss-fuzz-build-logs.storage.googleapis.com/index.html#oak

Step #4: ERROR: /builder/home/.cache/bazel/_bazel_root/872aac72dffae06b4e2a5b0308508d03/external/com_google_absl/absl/base/BUILD.bazel:171:1: undeclared inclusion(s) in rule '@com_google_absl//absl/base:base':
Step #4: this rule is missing dependency declarations for the following files included by 'external/com_google_absl/absl/base/internal/unscaledcycleclock.cc':
Step #4:   '/usr/local/lib/clang/10.0.0/share/asan_blacklist.txt'

And each time we run fuzzing - the library that causes the problem randomly changes.

I have found a flag, that causes this behavior:

$ bazel build --cxxopt=-fsanitize=address //oak/server:wasm_node
INFO: Analyzed target //oak/server:wasm_node (0 packages loaded, 0 targets configured).
INFO: Found 1 target...
ERROR: /root/.cache/bazel/_bazel_root/872aac72dffae06b4e2a5b0308508d03/external/com_google_absl/absl/numeric/BUILD.bazel:27:1: undeclared inclusion(s) in rule '@com_google_absl//absl/numeric:int128':
this rule is missing dependency declarations for the following files included by 'external/com_google_absl/absl/numeric/int128.cc':
  '/usr/local/lib/clang/10.0.0/share/asan_blacklist.txt'
Target //oak/server:wasm_node failed to build

I get this error even after bazel clean --expunge.

It seems that the address sanitizer implicitly adds a dependency on /usr/local/lib/clang/10.0.0/share/asan_blacklist.txt in every compiled file (even external ones). And Bazel could not compile targets because all dependencies should be explicitly included in BUILD files.

Another project that has the same issue is gRPC: https://oss-fuzz-build-logs.storage.googleapis.com/index.html#grpc cc @tiziano88 @yang-g @Dor1s

More information on the issue: https://github.com/project-oak/oak/issues/349

My project aspell does not seam to be using the seed corpus. About two days ago I expanded the seed corpus to improve coverage and yet coverage has not changed.

The files are currently not named based on the sha1 checksum. Is this a requirement? The manual strongly hints at this when it says:

The name of each file in the corpus is the sha1 checksum (which you can get using the sha1sum or shasum comand) of its contents.

• [x] bad_example Failed to get list of targets from "https://storage.googleapis.com/clusterfuzz-builds/bad_example/targets.list.address". as the target is not being run on CF
• [x] chakra The same root cause: Failed to get list of targets from "https://storage.googleapis.com/clusterfuzz-builds/chakra/targets.list.address".
• [x] dlplibs the disk is full, cannot unpack the corpus:

I  Step #4: /corpus/mswksfuzzer/5baeffd6604290d2cbea9a2112181f6c7b91ea0c:  write error (disk full?).  Continue? (y/n/^C)  
I  Step #4: warning:  /corpus/mswksfuzzer/5baeffd6604290d2cbea9a2112181f6c7b91ea0c is probably truncated 
I  Step #4: checkdir:  cannot create extraction directory: /corpus/mswrdfuzzer 
I  Step #4:            No space left on device 
I  Step #4: checkdir:  cannot create extraction directory: /corpus/multiplanfuzzer 
I  Step #4:            No space left on device 

• [x] example download_corpus failed, target is disabled on CF
• [x] firefox the disk is full, cannot finish compilation

I  Step #2: + find media/webrtc/trunk/webrtc/test/fuzzers/corpora/stun-corpus -type f -exec zip -qju /workspace/out/profile/StunParser_seed_corpus.zip '{}' ';' 
I  Step #2: + cp media/webrtc/trunk/webrtc/test/fuzzers/corpora/stun.tokens /workspace/out/profile/StunParser.dict 
I  Step #2: cp: error writing '/workspace/out/profile/work/obj-fuzz/_tests/testing/mochitest/chrome/toolkit/mozapps/update/tests/data/updater': No space left on device 
I  Step #2: cp: cannot create directory '/workspace/out/profile/work/obj-fuzz/_tests/testing/mochitest/chrome/toolkit/components': No space left on device 

• [x] fuzzing-puzzles The project is disabled: Failed to get list of targets from "https://storage.googleapis.com/clusterfuzz-builds/fuzzing-puzzles/targets.list.address".
• [x] glib Compilation failure. Weird, as I've added -ldl flag. Looks like the project does linking using clang, not clang++:

I  Step #2: [773/955] Linking target gio/gsettings. 
I  Step #2: FAILED: gio/gsettings  
I  Step #2: clang  -o gio/gsettings 'gio/gio@@gsettings@exe/gsettings-tool.c.o' -Wl,--no-undefined -Wl,--as-needed -O1 -fno-omit-frame-pointer -gline-tables-only -DFUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION -fprofile-instr-generate -fcoverage-mapping -pthread -Wl,-ldl -Wno-unused-command-line-argument -Wl,--start-group gio/libgio-2.0.a gio/xdgmime/libxdgmime.a gio/inotify/libinotify.a glib/libglib-2.0.a glib/libcharset/libcharset.a glib/pcre/libpcre.a gobject/libgobject-2.0.a subprojects/libffi/src/libffi.a subprojects/zlib-1.2.11/libz.a gmodule/libgmodule-2.0.a -lresolv -Wl,--end-group   
I  Step #2: gmodule/libgmodule-2.0.a(gmodule.c.o): In function `_g_module_self': 
I  Step #2: /work/meson/../../src/glib/gmodule/gmodule-dl.c:125: undefined reference to `dlopen' 
I  Step #2: gmodule/libgmodule-2.0.a(gmodule.c.o): In function `_g_module_open': 
I  Step #2: /work/meson/../../src/glib/gmodule/gmodule-dl.c:98: undefined reference to `dlopen' 
I  Step #2: gmodule/libgmodule-2.0.a(gmodule.c.o): In function `_g_module_close': 
I  Step #2: /work/meson/../../src/glib/gmodule/gmodule-dl.c:150: undefined reference to `dlclose' 
I  Step #2: gmodule/libgmodule-2.0.a(gmodule.c.o): In function `_g_module_symbol': 
I  Step #2: /work/meson/../../src/glib/gmodule/gmodule-dl.c:163: undefined reference to `dlsym' 
I  Step #2: gmodule/libgmodule-2.0.a(gmodule.c.o): In function `fetch_dlerror': 
I  Step #2: /work/meson/../../src/glib/gmodule/gmodule-dl.c:80: undefined reference to `dlerror' 
I  Step #2: clang-7: error: linker command failed with exit code 1 (use -v to see invocation) 

• [x] jsc The project is disabled: Failed to get list of targets from "https://storage.googleapis.com/clusterfuzz-builds/jsc/targets.list.address".
• [x] libchewing The target doesn't have corpus backups as it's disabled: https://github.com/google/oss-fuzz/blob/master/projects/libchewing/project.yaml#L2
• [x] libprotobuf-mutator Compilation failure without a reasonable error message:

I  Step #2: [208/209] Building CXX object CMakeFiles/protoc.dir/src/libprotobuf-mutator/build/external.protobuf/src/external.protobuf/src/google/protobuf/compiler/main.cc.o 
I  Step #2: [209/209] Linking CXX executable protoc 
I  Step #2: ninja: build stopped: subcommand failed. 
I  Finished Step #2 
I  ERROR 
I  ERROR: build step 2 "gcr.io/oss-fuzz/libprotobuf-mutator" failed: exit status 1 

Regular build has the same problem though: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10003

• [x] libpsl Compilation failure:

I  Step #2:   CCLD     psl 
I  Step #2: /usr/bin/ld: /src/deps/lib/libicuuc.a(putil.ao): undefined reference to symbol 'floor@@GLIBC_2.2.5' 
I  Step #2: //lib/x86_64-linux-gnu/libm.so.6: error adding symbols: DSO missing from command line 
I  Step #2: clang-7: error: linker command failed with exit code 1 (use -v to see invocation) 
I  Step #2: make[2]: *** [psl] Error 1 
I  Step #2: Makefile:468: recipe for target 'psl' failed 

• [x] libssh Compilation failure, the same as the regular build has.

I  Step #2: CMake Error at cmake/Modules/CheckCCompilerFlagSSP.cmake:19 (include_guard): 
I  Step #2:   Unknown CMake command "include_guard". 
I  Step #2: Call Stack (most recent call first): 
I  Step #2:   CompilerChecks.cmake:2 (include) 
I  Step #2:   CMakeLists.txt:31 (include) 
I  Step #2:  
I  Step #2:  
I  Step #2: -- Configuring incomplete, errors occurred! 
I  Step #2: See also "/src/libssh/build/CMakeFiles/CMakeOutput.log". 

• [x] mercurial Corpus download failed, probably because https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=9694 xdiff_fuzzer seems to be crazy slow so corpus pruning never finishes since early July
• [x] nss No fuzz targets (weird): Failed to get list of targets from "https://storage.googleapis.com/clusterfuzz-builds/nss/targets.list.address".
• [x] openvswitch Build failure:

I  Step #2: + clang++ -O1 -fno-omit-frame-pointer -gline-tables-only -DFUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION -fprofile-instr-generate -fcoverage-mapping -pthread -Wl,-ldl -Wno-unused-command-line-argument -stdlib=libc++ /workspace/out/profile/flow_extract_target.o ./lib/.libs/libopenvswitch.a -lz -lssl -lcrypto -latomic -lFuzzingEngine -o /workspace/out/profile/flow_extract_fuzzer 
I  Step #2: ./lib/.libs/libopenvswitch.a(async-append-aio.o): In function `async_append_write': 
I  Step #2: /src/openvswitch/lib/async-append-aio.c:144: undefined reference to `aio_write' 
I  Step #2: ./lib/.libs/libopenvswitch.a(async-append-aio.o): In function `async_append_wait': 
I  Step #2: /src/openvswitch/lib/async-append-aio.c:99: undefined reference to `aio_error' 
I  Step #2: /src/openvswitch/lib/async-append-aio.c:106: undefined reference to `aio_suspend' 
I  Step #2: /src/openvswitch/lib/async-append-aio.c:108: undefined reference to `aio_return' 
I  Step #2: clang-7: error: linker command failed with exit code 1 (use -v to see invocation) 

• [x] postgis Corpus download failed. Missing corpus backup for postgis_wkb_import_fuzzer.
• [x] proj4 Build failure (messing up with atexit which is used for dumping coverage):

I  Step #2: clang-7: error: linker command failed with exit code 1 (use -v to see invocation) 
I  Step #2: /usr/bin/ld: .libs/basic_test: hidden symbol `atexit' in /usr/lib/x86_64-linux-gnu/libc_nonshared.a(atexit.oS) is referenced by DSO 
I  Step #2: /usr/bin/ld: final link failed: Bad value 
I  Step #2: make[2]: *** [proj_errno_string_test] Error 1 
I  Step #2: Makefile:424: recipe for target 'proj_errno_string_test' failed 
I  Step #2: clang-7: error: linker command failed with exit code 1 (use -v to see invocation) 
I  Step #2: make[2]: *** [basic_test] Error 1 
I  Step #2: Makefile:416: recipe for target 'basic_test' failed 
I  Step #2: Makefile:369: recipe for target 'all-recursive' failed 
I  Step #2: make[1]: *** [all-recursive] Error 1 
I  Step #2: make: *** [all-recursive] Error 1 
I  Step #2: Makefile:448: recipe for target 'all-recursive' failed 

• [x] spidermonkey No fuzz targets, WAI: Failed to get list of targets from "https://storage.googleapis.com/clusterfuzz-builds/spidermonkey/targets.list.address".
• [x] strongswan Build failure. Not sure what's going on, by adding -lm likely will solve the problem:

I  Step #2: rm -f libFuzzerLocal.a 
I  Step #2: ar cru libFuzzerLocal.a libFuzzerLocal.o ../src/libstrongswan/libstrongswan.la 
I  Step #2: ar: `u' modifier ignored since `D' is the default (see `U') 
I  Step #2: ranlib libFuzzerLocal.a 
I  Step #2: /usr/lib/libFuzzingEngine.a(FuzzerLoop.o): In function `ceil': 
I  Step #2: /usr/local/bin/../include/c++/v1/math.h:834: undefined reference to `ceilf' 
I  Step #2: /usr/local/bin/../include/c++/v1/math.h:834: undefined reference to `ceilf' 

This depends on changes that haven't landed in CPython yet. You can test it by replacing the git clone with:

RUN git clone -b fix-issue-29505 --depth 1 https://github.com/ssbr/cpython.git cpython

The corresponding pull request to CPython is here: https://github.com/python/cpython/pull/2878

Those are the first fuzz tests I've ever written, and maybe are too trivial or something. Will get to better fuzz tests soon.

Extra notes: Google bug: b/37562550 (and there are others for other bits of CPython) Python bug: https://bugs.python.org/issue29505

Fuzzer for Python port of Google's libphonenumber

Tests mentioned in docs have been run:

python infra/helper.py build_image python-phonenumbers
python infra/helper.py build_fuzzers --sanitizer address python-phonenumbers
python infra/helper.py check_build python-phonenumbers
python infra/helper.py run_fuzzer python-phonenumbers python_phonenumbers_fuzzer

https://github.com/openconfig/ygot/actions/runs/3859702213/jobs/6579479054

/usr/local/bin/compile_go_fuzzer: line 28: cd: /root/go/src/github.com/openconfig/ygot/exampleoc: No such file or directory

Looks similar to the failure that was fixed by https://github.com/google/oss-fuzz/pull/5476

Step #3: + compile_go_fuzzer ./exampleoc Fuzz fuzz_oc_unmarshall gofuzz
Step #3: /usr/local/bin/compile_go_fuzzer: line 28: cd: /root/go/src/./exampleoc: No such file or directory

We are transitioning from libhtp C to libhtp in rust

So, here is the update of the project to fuzz the coming rust version, and also do differential fuzzing between them to check that they have the same behavior...

Dear OSS-Fuzz users, I've been experimenting with running TSAN on OSS-Fuzz projects. Before we have any real support for this, I want to know if users are interested. If you are interested, please leave a thumbs up on this issue. Also if you're interested in me giving you bugs I've already found in your project using TSAN leave a comment.

Note: I may still reach out even if you don't comment here (since not everyone watches all of our issues).