The vulnerability exists in how the Wasmtime Rust API handles WebAssembly shared linear memories. The core issue is that wasmtime::Memory, a type designed for non-shared memories with safe, unsynchronized access, could be used to represent shared memories. This is unsound because shared memories can be modified by multiple threads concurrently, and unsynchronized access can lead to data races in the host application.
The analysis of the provided patch identified two key functions where this unsound behavior was permitted:
wasmtime::Memory::new: This constructor function allowed the direct creation of a wasmtime::Memory object from a shared MemoryType. The patch rectifies this by adding a check to explicitly forbid shared memory types, forcing the use of the correct wasmtime::SharedMemory::new constructor.
wasmtime::WasmCoreDump::new: This function, used for creating core dumps, would iterate over all memories in the store and include them in the dump. This process treated shared memories as standard wasmtime::Memory objects, creating a risk of data races during the dump's creation. The patch mitigates this by filtering out and excluding shared memories from the core dump.
Both functions are entry points for the same fundamental flaw: incorrectly applying the wasmtime::Memory abstraction to shared memory. An attacker could trigger this by crafting a WebAssembly module that uses shared memory and then either explicitly creating a Memory object or triggering a trap that generates a core dump.
| Package Name | Ecosystem | Vulnerable Versions | First Patched Version |
|---|---|---|---|
| wasmtime | rust | >= 38.0.0, < 38.0.4 | 38.0.4 |
| wasmtime | rust | >= 37.0.0, < 37.0.3 | 37.0.3 |
| wasmtime | rust | >= 26.0.0, < 36.0.3 | 36.0.3 |
| wasmtime | rust | < 24.0.5 | 24.0.5 |