CVE-2022-39392

Wasmtime is a standalone runtime for WebAssembly. Prior to version 2.0.2,
there is a bug in Wasmtime’s implementation of its pooling instance
allocator when the allocator is configured to give WebAssembly instances a
maximum of zero pages of memory. In this configuration, the virtual memory
mapping for WebAssembly memories did not meet the compiler-required
configuration requirements for safely executing WebAssembly modules.
Wasmtime’s default settings require virtual memory page faults to indicate
that wasm reads/writes are out-of-bounds, but the pooling allocator’s
configuration would not create an appropriate virtual memory mapping for
this meaning out of bounds reads/writes can successfully read/write memory
unrelated to the wasm sandbox within range of the base address of the
memory mapping created by the pooling allocator. This bug is not applicable
with the default settings of the wasmtime crate. This bug can only be
triggered by setting InstanceLimits::memory_pages to zero. This is
expected to be a very rare configuration since this means that wasm modules
cannot allocate any pages of linear memory. All wasm modules produced by
all current toolchains are highly likely to use linear memory, so it’s
expected to be unlikely that this configuration is set to zero by any
production embedding of Wasmtime. This bug has been patched and users
should upgrade to Wasmtime 2.0.2. This bug can be worked around by
increasing the memory_pages allotment when configuring the pooling
allocator to a value greater than zero. If an embedding wishes to still
prevent memory from actually being used then the Store::limiter method
can be used to dynamically disallow growth of memory beyond 0 bytes large.
Note that the default memory_pages value is greater than zero.

Notes