2017-09-06 15:15:35 -03:00
|
|
|
Fuzz Tests for CPython
|
|
|
|
======================
|
|
|
|
|
|
|
|
These fuzz tests are designed to be included in Google's `oss-fuzz`_ project.
|
|
|
|
|
|
|
|
oss-fuzz works against a library exposing a function of the form
|
|
|
|
``int LLVMFuzzerTestOneInput(const uint8_t* data, size_t length)``. We provide
|
|
|
|
that library (``fuzzer.c``), and include a ``_fuzz`` module for testing with
|
|
|
|
some toy values -- no fuzzing occurs in Python's test suite.
|
|
|
|
|
|
|
|
oss-fuzz will regularly pull from CPython, discover all the tests in
|
|
|
|
``fuzz_tests.txt``, and run them -- so adding a new test here means it will
|
|
|
|
automatically be run in oss-fuzz, while also being smoke-tested as part of
|
|
|
|
CPython's test suite.
|
|
|
|
|
2023-10-09 12:30:10 -03:00
|
|
|
In addition, the tests are run on GitHub Actions using CIFuzz for PRs to the
|
|
|
|
main branch changing relevant files.
|
|
|
|
|
2017-09-06 15:15:35 -03:00
|
|
|
Adding a new fuzz test
|
|
|
|
----------------------
|
|
|
|
|
|
|
|
Add the test name on a new line in ``fuzz_tests.txt``.
|
|
|
|
|
|
|
|
In ``fuzzer.c``, add a function to be run::
|
|
|
|
|
2024-09-16 17:28:09 -03:00
|
|
|
static int $fuzz_test_name(const char* data, size_t size) {
|
2017-09-06 15:15:35 -03:00
|
|
|
...
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
And invoke it from ``LLVMFuzzerTestOneInput``::
|
|
|
|
|
2024-09-16 17:28:09 -03:00
|
|
|
#if !defined(_Py_FUZZ_ONE) || defined(_Py_FUZZ_$fuzz_test_name)
|
|
|
|
rv |= _run_fuzz(data, size, $fuzz_test_name);
|
2017-09-06 15:15:35 -03:00
|
|
|
#endif
|
|
|
|
|
2024-09-16 17:28:09 -03:00
|
|
|
Don't forget to replace ``$fuzz_test_name`` with your actual test name.
|
|
|
|
|
2017-09-06 15:15:35 -03:00
|
|
|
``LLVMFuzzerTestOneInput`` will run in oss-fuzz, with each test in
|
|
|
|
``fuzz_tests.txt`` run separately.
|
|
|
|
|
2019-06-12 01:30:35 -03:00
|
|
|
Seed data (corpus) for the test can be provided in a subfolder called
|
|
|
|
``<test_name>_corpus`` such as ``fuzz_json_loads_corpus``. A wide variety
|
|
|
|
of good input samples allows the fuzzer to more easily explore a diverse
|
|
|
|
set of paths and provides a better base to find buggy input from.
|
|
|
|
|
|
|
|
Dictionaries of tokens (see oss-fuzz documentation for more details) can
|
|
|
|
be placed in the ``dictionaries`` folder with the name of the test.
|
|
|
|
For example, ``dictionaries/fuzz_json_loads.dict`` contains JSON tokens
|
|
|
|
to guide the fuzzer.
|
|
|
|
|
2017-09-06 15:15:35 -03:00
|
|
|
What makes a good fuzz test
|
|
|
|
---------------------------
|
|
|
|
|
|
|
|
Libraries written in C that might handle untrusted data are worthwhile. The
|
|
|
|
more complex the logic (e.g. parsing), the more likely this is to be a useful
|
|
|
|
fuzz test. See the existing examples for reference, and refer to the
|
|
|
|
`oss-fuzz`_ docs.
|
|
|
|
|
|
|
|
.. _oss-fuzz: https://github.com/google/oss-fuzz
|