dccaa64962
Fuzzing has turned up that module linking can create large amounts of tables and memories in addition to instances. For example if N instances are allowed and M tables are allowed per-instance, then currently wasmtime allows MxN tables (which is quite a lot). This is causing some wasm-smith-generated modules to exceed resource limits while fuzzing! This commits adds corresponding `max_tables` and `max_memories` functions to sit alongside the `max_instances` configuration. Additionally fuzzing now by default configures all of these to a somewhat low value to avoid too much resource usage while fuzzing.
Fuzzing Infrastructure for Wasmtime
This crate provides test case generators and oracles for use with fuzzing.
These generators and oracles are generally independent of the fuzzing engine
that might be using them and driving the whole fuzzing process (e.g. libFuzzer
or AFL). As such, this crate does not contain any actual fuzz targets
itself. Those are generally just a couple lines of glue code that plug raw input
from (for example) libFuzzer into a generator, and then run one or more
oracles on the generated test case.
If you're looking for the actual fuzz target definitions we currently have, they
live in wasmtime/fuzz/fuzz_targets/* and are driven by cargo fuzz and
libFuzzer.