#Fuzzing In this folder, we keep our fuzzers (bits of code that takes a randomized input and executes code randomly, focusing on specific APIs). For example, we have a codec fuzzer which takes a mutated png/jpeg or similar file and attempts to turn it into an
SkImage. We also have a canvas fuzzer which takes in a random set of bytes and turns them into calls on
These fuzzers are packaged in two different ways (see //BUILD.gn). There is a
fuzz executable that contains all fuzzers and is a convenient way to reproduce fuzzer-reported bugs. There are also single fuzzer executables containing exactly one fuzzer, which are convenient to build with libfuzzer.
See [../site/dev/testing/fuzz.md] for more information on building and running fuzzers using the
There is a Skia folder in the OSS-Fuzz repo that we make changes to when we want to add/remove/change the fuzzers that are automatically run. This describes how to test the OSS-Fuzz build and fuzzers locally using Docker.
When enabling a fuzzer in OSS-Fuzz, we typically need to follow these steps:
gs://skia-fuzzer/oss-fuzz/(in the skia-public project). Make sure the corpus file is public-readable. It is easiest to add this permission via the web UI. This is done by granting the allUsers “name” the Reader role to the zip file. See the infra team if you do not have access to this bucket.
_seed_corpus.zipas a suffix.
*For fuzzers who depend strongly on the format of the randomized data, e.g. image decoding, SkSL parsing. These are called binary fuzzers, as opposed to API fuzzers.
https://oss-fuzz.com/fuzzer-stats is useful to see metrics on how our fuzzers are running. It shows things like executions per second (higher is better), edge coverage percent per fuzzer, what percent of fuzzing runs end in OOM/timeout/crash, the entire corpus of fuzzed inputs (corpus_backup), etc. Contact aarya@ to get permission to view this dashboard if necessary. Here are some example dashboards: