From e73446790ec20db6460dc44b79a956bad3e326d6 Mon Sep 17 00:00:00 2001 From: Alex Crichton Date: Wed, 9 Mar 2022 10:53:05 -0600 Subject: [PATCH] fuzz: Limit memories in the instantiate-many fuzzer (#3902) A fuzz bug was hit last night where the root of the fuzz bug appears to be exhaustion of the virtual address space. The specific case in question instantiated a module with ~100 memories ~100 times, and each memory reserved ~8gb of the virtual address space. This takes around 47 bits of addressable memory which is mighty close to the limit of what can be done on x86_64, so this commit reduces the number of memories that an instance may have when coming out of `wasm-smith`. --- fuzz/fuzz_targets/instantiate-many.rs | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/fuzz/fuzz_targets/instantiate-many.rs b/fuzz/fuzz_targets/instantiate-many.rs index 351da977ed..a562abe378 100644 --- a/fuzz/fuzz_targets/instantiate-many.rs +++ b/fuzz/fuzz_targets/instantiate-many.rs @@ -24,6 +24,16 @@ fn run(data: &[u8]) -> Result<()> { // use timeouts or ensure that the generated wasm code will terminate. config.module_config.config.allow_start_export = false; + // Wasm linear memories take roughly ~8gb of virtual address space. Down + // below we could instantiate up to 300 modules. Conservatively estimating + // that we have 46 bits of address space to work with (technically 48 on + // x86_64, but take some out for kernel stuff and some for asan stuff) that + // gives us a budget of ~27 memories per instance. Reduce that a bit further + // and make sure that no instance has more than 10 linear memories to ensure + // that even if the maximum were created it should still fit in the linear + // address space. + config.module_config.config.max_memories = config.module_config.config.max_memories.min(10); + // Create the modules to instantiate let modules = (0..u.int_in_range(1..=MAX_MODULES)?) .map(|_| Ok(config.generate(&mut u, None)?.to_bytes()))