bytecodealliance wasmtime
cpe:2.3:a:bytecodealliance:wasmtime:*:*:*:*:rust:*:*
- <= 38.0.3
A vulnerability exists in Wasmtime's Rust embedder API regarding the management of WebAssembly shared linear memory. In versions prior to 38.0.4, 37.0.3, 36.0.3, and 24.0.5, the API allowed shared linear memory to be represented as a type that provided safe access to its contents from the host. This representation is inherently unsafe, as shared memories can be modified concurrently, potentially leading to data races in the host environment. The issue arises because Wasmtime's `Memory` type, which is designed for non-shared memories, incorrectly allows the representation of shared linear memories. Embeddings that do not utilize the WebAssembly threads proposal or create shared memories are not affected.
The vulnerability could cause data races in the host application, where concurrent modifications to shared memory by different threads could lead to inconsistent or unexpected behavior.
The vulnerability can be reproduced by creating a WebAssembly module that uses shared linear memory and importing it into a Wasmtime instance using the Rust embedder API. This can be done by enabling the WebAssembly threads proposal and using the `wasmtime::Memory::new` method to create shared memory, which is not properly validated. Once the module is executed, a core dump can be triggered, which will unsafely read the shared memory and expose the data race condition.
Users should upgrade to Wasmtime versions 38.0.4, 37.0.3, 36.0.3, or 24.0.5, all of which include the necessary fix. After upgrading, shared memories should be created using the `SharedMemory::new` method instead of `Memory::new`. If an upgrade is not possible, core dumps can be disabled to prevent the unsynchronized read of shared memory.
Our algorithm analyzes dozens of metrics to generate these 8 key vulnerability categories, which are then combined to calculate the overall risk score.