366da3eb14
In PR #9719 I accidentally added the memory sanitizer, which brakes the oss-fuzz build: ``` Step #23 - "compile-libfuzzer-memory-x86_64": ld.lld: error: undefined symbol: __msan_param_tls Step #23 - "compile-libfuzzer-memory-x86_64": >>> referenced by gtest-internal.h:522 (external/com_google_googletest/googletest/include/gtest/internal/gtest-internal.h:522) Step #23 - "compile-libfuzzer-memory-x86_64": >>> bazel-out/k8-fastbuild-ST-d2373e19ffe2/bin/test/common/router/_objs/config_impl_test_lib/config_impl_test.pic.o:(testing::internal::SuiteApiResolver<Envoy::Router::(anonymous namespace)::RouteMatcherTest>::GetSetUpCaseOrSuite(char const*, int)) Step #23 - "compile-libfuzzer-memory-x86_64": >>> referenced by gtest-internal.h:543 (external/com_google_googletest/googletest/include/gtest/internal/gtest-internal.h:543) Step #23 - "compile-libfuzzer-memory-x86_64": >>> bazel-out/k8-fastbuild-ST-d2373e19ffe2/bin/test/common/router/_objs/config_impl_test_lib/config_impl_test.pic.o:(testing::internal::SuiteApiResolver<Envoy::Router::(anonymous namespace)::RouteMatcherTest>::GetTearDownCaseOrSuite(char const*, int)) Step #23 - "compile-libfuzzer-memory-x86_64": >>> referenced by gtest-internal.h:522 (external/com_google_googletest/googletest/include/gtest/internal/gtest-internal.h:522) Step #23 - "compile-libfuzzer-memory-x86_64": >>> bazel-out/k8-fastbuild-ST-d2373e19ffe2/bin/test/common/router/_objs/config_impl_test_lib/config_impl_test.pic.o:(testing::internal::SuiteApiResolver<Envoy::Router::(anonymous namespace)::HeaderTransformsDoFormattingTest>::GetSetUpCaseOrSuite(char const*, int)) Step #23 - "compile-libfuzzer-memory-x86_64": >>> referenced 377754 more times ``` This PR keeps the address and undefined sanitizer. Signed-off-by: Adi Suissa-Peleg <adip@google.com> |
||
|---|---|---|
| .allstar | ||
| .clusterfuzzlite | ||
| .github | ||
| docs | ||
| infra | ||
| projects | ||
| .dockerignore | ||
| .gitattributes | ||
| .gitignore | ||
| .pylintrc | ||
| .style.yapf | ||
| CONTRIBUTING.md | ||
| LICENSE | ||
| README.md | ||
README.md
OSS-Fuzz: Continuous Fuzzing for Open Source Software
Fuzz testing is a well-known technique for uncovering programming errors in software. Many of these detectable errors, like buffer overflow, can have serious security implications. Google has found thousands of security vulnerabilities and stability bugs by deploying guided in-process fuzzing of Chrome components, and we now want to share that service with the open source community.
In cooperation with the Core Infrastructure Initiative and the OpenSSF, OSS-Fuzz aims to make common open source software more secure and stable by combining modern fuzzing techniques with scalable, distributed execution. Projects that do not qualify for OSS-Fuzz (e.g. closed source) can run their own instances of ClusterFuzz or ClusterFuzzLite.
We support the libFuzzer, AFL++, and Honggfuzz fuzzing engines in combination with Sanitizers, as well as ClusterFuzz, a distributed fuzzer execution environment and reporting tool.
Currently, OSS-Fuzz supports C/C++, Rust, Go, Python, Java/JVM, and JavaScript code. Other languages supported by LLVM may work too. OSS-Fuzz supports fuzzing x86_64 and i386 builds.
Overview
Documentation
Read our detailed documentation to learn how to use OSS-Fuzz.
Trophies
As of February 2023, OSS-Fuzz has helped identify and fix over 8,900 vulnerabilities and 28,000 bugs across 850 projects.
Blog posts
- 2016-12-01 - Announcing OSS-Fuzz: Continuous fuzzing for open source software
- 2017-05-08 - OSS-Fuzz: Five months later, and rewarding projects
- 2018-11-06 - A New Chapter for OSS-Fuzz
- 2020-10-09 - Fuzzing internships for Open Source Software
- 2020-12-07 - Improving open source security during the Google summer internship program
- 2021-03-10 - Fuzzing Java in OSS-Fuzz
- 2021-12-16 - Improving OSS-Fuzz and Jazzer to catch Log4Shell
- 2022-09-08 - Fuzzing beyond memory corruption: Finding broader classes of vulnerabilities automatically
- 2023-02-01 - Taking the next step: OSS-Fuzz in 2023