Doesn't affect final binaries as they wouldn't link not needed objects,
but we can make the build skip some not needed targets that would
otherwise be build by meson.
This commit updates the default version of Rust installed for fuzzing to
the last nightly of Rust that used LLVM 17. The next version uses LLVM
18.1.7 which is incompatible with the fuzz infrastructure's own LLVM
which is currently 18.0.0. This is intended to update the Rust toolchain
as far as possible without causing coverage incompatibilities.
This additionally updates a few pinned projects to all use this nightly
as well. Furthermore the containers are now configured to by-default
ignore `rust-toolchain` and `rust-toolchain.toml` files which will force
this particular toolchain to be used.
An attempt to fix two issues:
- sporadic `No space left on device` during build check
- `/usr/local/bin/compile: line 333: 11681 Killed python3
/fuzz-introspector/src/main.py report $REPORT_ARGS`
Disabling FFmpeg filters is unfortunate, as it reduces coverage of
filtering code, but lets focus on stabilizing the core code first.
Introspector fail is likely an OOM error, not sure if this commit will
help with it.
Generally mpv is not that big project, so those failures are not
expected, but lets try to workaround the limitations.
The original corpus of QuickJS consisted of a few large files that were
too complex; some contained benchmarks, others had tests spread across
multiple files or were scattered with assertions. The new corpus was
created by breaking down and transforming these tests into smaller,
fuzzing-optimized pieces.
I set `disabled` to true because LeakSanitizer claims the fuzzers have
leaks. However, this is not true because bc and dc run without leaks
under Valgrind.
After some debugging, I can cause them to free the memory by putting an
`assert(false);` after all of the frees [1] [2], and it trips. But if I
remove it, LeakSanitizer sees leaks.
Whether it's PEBKAC (probably) or miscompilation (unlikely), I don't
know, but I figured I'd commit the necessary stuff for the project.
I'll try to figure out the problem later.
[1]: https://github.com/gavinhoward/bc/blob/master/src/bc_fuzzer.c#L110
[2]: https://github.com/gavinhoward/bc/blob/master/src/dc_fuzzer.c#L110
Signed-off-by: Gavin D. Howard <gavin@gavinhoward.com>
clang/llvm are only bumped on a manual basis, due to requiring a full
infra build. Thus, remove the code to support the rolling chromium
nightly clang.
Also, extend the docs around `CMAKE_VERSION`. The removal of the docs
around `FORCE_OUR_REVISION` also remove the mention of
https://github.com/google/oss-fuzz/issues/7273, so this also fixes
https://github.com/google/oss-fuzz/issues/7273.
Co-authored-by: MarcoFalke <6399679+MarcoFalke@users.noreply.github.com>
The build currently fails with the following error:
```
+ meson setup --prefix=/work/prefix --libdir=lib --default-library=static _builddir
The Meson build system
Version: 1.2.0
Source dir: /src/cairo
Build dir: /src/cairo/_builddir
Build type: native build
meson.build:2:17: ERROR: Meson version is 1.2.0 but project requires >= 1.3.0
A full log can be found at /src/cairo/_builddir/meson-logs/meson-log.txt
```
OSS-Fuzz already ships with a more recent cmake, so skip installing a
prior version in the msquic project.
This speeds up the build and reduces the storage needs. Also, future
clang compiler bumps may be smoother.
Co-authored-by: MarcoFalke <6399679+MarcoFalke@users.noreply.github.com>
Instead of rebuilding the entire project every time we want to compile a
single fuzz target, a better workflow is to build the project once and
somehow compile the target against the already compiled project code.
This POC does that by interrupting building in when it detects it is
compiling the fuzz target.
On detection it does the following:
1. Writes the command to /out/statefile TODO: write the cwd.
2. Commits the current container as "frozen" for use later. TODO: make
this changeable.
3. Returns 1 so compilation stops. TODO: It would be better to exit the
container.
This step may be important to prevent clean up of the environment.
Then the frozen container can be used to compile fuzz targets against
the project without recompiling the project in its entirety.
TODO:
1. Support this in oss-fuzz-gen
2. Install docker command line tool in base-builder (or use sneaky
inheritance) because it must be used within the container.
3. Automate the compilation of the new fuzz target
Remove build.sh and change Dockerfile. The build script location fits
the upstream file organization in `OpenPrinting/fuzzing`.
Signed-off-by: TTFISH <jiongchiyu@gmail.com>
It's kind of a follow-up to https://github.com/secdev/scapy/pull/4381
ans should help to catch issues like that going forward.
@gpotter2 @guedou @p-l- could you take a look?
(I think ideally it would be nice to move the fuzz target to the scapy
repository where it could be changed and reviewed without having to open
PRs here)
The OpenPrinting project under the Linux Foundation has initiated the
[OpenPrinting fuzzing](https://github.com/OpenPrinting/fuzzing)
repository to officially maintain OSS-Fuzz testing tasks. This PR
includes following updates:
1. Migration of the existing CUPS fuzzing harness to the upstream
OpenPrinting/fuzzing project.
2. Updated of CUPS mailing contact list and configuration setting.
All harness building related changes has been locally tested and
verified.
We deeply appreciate the contributions from @pkillarjun for his initial
integration of the CUPS project into OSS-Fuzz and his support during
this migration. However, OpenPrinting has decided to move the corpus,
fuzzing harnesses, and build scripts into the repository under its
organisation and maintainance. In addition, the bug reports will be
firstly processed by OpenPrinting's security team and not by the initial
contributor, who is not part of the organisation. These two measures
will minimise the security risks and still maintaining the ability of
open source fellows to participate in the development.
CC @tillkamppeter @iosifache
---------
Signed-off-by: TTFISH <jiongchiyu@gmail.com>
#### In the Fuzz Harnesses
Adds additional handling for shallow errors that prematurely halt fuzzer
runs.
#### In `build.sh`
Fixes an issue preventing Pyinstaller from properly bundling
`lxml.isoschematron`. The issue fixed here can be seen in the build logs
(e.g, [the most recent
one](https://oss-fuzz-build-logs.storage.googleapis.com/log-c5377ff0-29ca-4541-bda2-1159016ec4a6.txt))
by `grep`ing for the string `Failed to collect submodules`
---
More details about these changes can be found in their respective commit
messages.
as newer compilers have deprecated some features used by old boost.
Specifically:
```
/src/boost/boost/container_hash/hash.hpp:131:33: error: no template named 'unary_function' in namespace 'std'; did you mean '__unary_function'?
131 | struct hash_base : std::unary_function<T, std::size_t> {};
| ~~~~~^~~~~~~~~~~~~~
| __unary_function
```
pikepdf is a Python library allowing creation, manipulation and repair
of PDFs. It provides a Pythonic wrapper around the C++ PDF content
transformation library, QPDF. It is used by over 3800 repositories and
90 packages. Most notably, OCRmyPDF (12,400+ stars) uses pikepdf to
graft OCR text layers onto existing PDFs, to examine the contents of
input PDFs, and to optimize PDFs. Additionally, PDFArranger (3000+
stars) depends on pikepdf and is a Python application that provides a
graphical user interface to rotate, crop and rearrange PDFs. It is
important that fuzzing be integrarted into pikepdf as the domino effect
of a high or critical vulnerability in pikepdf would cause numerous
other open source software products to be vulnerable as well.
Approval from the upstream maintainer can be found here:
https://github.com/pikepdf/pikepdf/issues/587
The OpenPrinting Team is integrating C-based projects into the OSS-Fuzz
Framework. The maintaining fuzz harnesses locate in OpenPrinting project
[fuzzing](https://github.com/OpenPrinting/fuzzing).
This PR contains the initial integration config for OpenPrinting project
libcups.
CC: @tillkamppeter @iosifache
---------
Signed-off-by: TTFISH <jiongchiyu@gmail.com>
Sashan