Alexcrichton

**Name of the Vulnerable Software and Affected Versions** Wasmtime versions prior to 36.0.8 Wasmtime versions prior to 43.0.2 Wasmtime versions prior to 44.0.1 **Description** Allocation logic for a WebAssembly table contains checked arithmetic that panics on overflow when a table with an extremely large size is allocated. This occurs during the instantiation of a WebAssembly module or component and is possible when the `memory64` WebAssembly feature is enabled, allowing table sizes in the 64-bit range. The issue specifically affects the on-demand instance allocator, which is the default allocator, and can lead to a denial-of-service by causing the host process to panic. **Recommendations** Update to version 36.0.8. Update to version 43.0.2. Update to version 44.0.1. Switch to using the pooling allocator. Disable the `memory64` WebAssembly proposal.

**Name of the Vulnerable Software and Affected Versions** Wasmtime versions 39.0.0 through 41.0.3 **Description** Wasmtime, a runtime for WebAssembly, can experience a panic when the host embedder drops the future returned by `wasmtime::component::[Typed]Func::call async` before it resolves, and then calls the same function again with the same component instance. This occurs because the component instance enters a non-reenterable state, leading to a trap and subsequent panic during task disposal. The issue arises from a bug in the implementation of `[Typed]Func::call async` introduced with the `component-model-async` feature, which became the default starting with version 39.0.0. The `API Endpoint` involved is `wasmtime::component::[Typed]Func::call async`. The `variable` representing the returned future is not explicitly named, but its improper handling triggers the issue. The issue does not affect embeddings with the `component-model-async` compile-time feature disabled. **Recommendations** Wasmtime versions 39.0.0 through 40.0.3 should be updated to version 40.0.4 or 41.0.4. Wasmtime versions 40.0.4 through 41.0.3 should be updated to version 41.0.4. If an embedding is not using any component-model-async features, disable the `component-model-async` Cargo feature. Ensure every `call async` future is awaited until it completes. Refrain from using the `Store` again after dropping a not-yet-resolved `call async` future.

**Name of the Vulnerable Software and Affected Versions** Wasmtime versions prior to 24.0.6 Wasmtime versions prior to 36.0.6 Wasmtime version 4.0.04 Wasmtime versions prior to 41.0.4 Wasmtime versions prior to 42.0.0 **Description** Wasmtime's implementation of the `wasi:http/types.fields` resource is susceptible to panics when an excessive number of fields are added to the set of headers. The `wasmtime-wasi-http` crate uses a data structure that panics when it reaches its capacity, and this condition was not handled gracefully. A panic in a WASI implementation can lead to a Denial of Service for embedders. **Recommendations** Update to Wasmtime version 24.0.6 or later. Update to Wasmtime version 36.0.6 or later. Update to Wasmtime version 4.0.04 or later. Update to Wasmtime version 41.0.4 or later. Update to Wasmtime version 42.0.0 or later.

**Name of the Vulnerable Software and Affected Versions** Wasmtime versions 37.0.0 through 37.0.1 **Description** Wasmtime, a runtime for WebAssembly, contains memory leaks within its C/C++ API when utilizing bindings for `anyref` or `externref` WebAssembly values. This issue stems from a regression introduced during the development of version 37.0.0, specifically related to a refactoring from `ManuallyRooted<T>` to `OwnedRooted<T>` in Rust. The C and C++ APIs were not fully updated to reflect the new ownership semantics of `OwnedRooted<T>`, leading to memory leaks. Specifically, a typo in the `wasmtime val unroot` function prevented proper unrooting, and host-defined functions returning `wasmtime {externref,anyref} t` values were never unrooted. The C++ API lacked destructors on relevant types, further contributing to the issue. These leaks occur when `anyref` or `externref` are used in the C/C++ API, and the `wasmtime` Rust crate is not affected. **Recommendations** Update to Wasmtime version 37.0.2 or later to address the memory leaks in the C/C++ API. Avoid using `externref` and `anyref` in the C/C++ API of Wasmtime if updating is not immediately possible.

**Name of the Vulnerable Software and Affected Versions** Wasmtime versions 21.0.0 through 21.0.1 Wasmtime versions 22.0.0 through 22.0.0 Wasmtime versions 23.0.0 through 23.0.2 Wasmtime versions 24.0.0 through 24.0.0 Wasmtime versions 25.0.0 through 25.0.1 **Description** The issue is related to Wasmtime's implementation of WebAssembly tail calls combined with stack traces, which can result in a runtime crash in certain WebAssembly modules. This can happen when an exported function in a WebAssembly module performs a `return call` (or `return call indirect` or `return call ref`) to an imported host function that captures a stack trace. The crash is due to an internal assert in the stack-walking code that raises a Rust `panic!()`. The impact of this issue is a denial-of-service vector where a malicious WebAssembly module or component can cause the host to crash. There is no other impact at this time other than availability of a service as the result of the crash is always a crash and no more. **Recommendations** For Wasmtime versions 21.0.0 through 21.0.1, upgrade to version 21.0.2. For Wasmtime versions 22.0.0 through 22.0.0, upgrade to version 22.0.1. For Wasmtime versions 23.0.0 through 23.0.2, upgrade to version 23.0.3. For Wasmtime versions 24.0.0 through 24.0.0, upgrade to version 24.0.1. For Wasmtime versions 25.0.0 through 25.0.1, upgrade to version 25.0.2. As a temporary workaround, consider disabling tail call support in Wasmtime by setting `Config::wasm tail call(false)`.

**Name of the Vulnerable Software and Affected Versions** wasmtime versions prior to 4.0.1 wasmtime versions prior to 5.0.1 wasmtime versions prior to 6.0.1 **Description** The issue is related to a bug in the Cranelift code generator of wasmtime, which mistakenly calculates a 35-bit effective address instead of the defined 33-bit effective address for WebAssembly. This allows a malicious module to read or write memory up to 34G away from the base of linear memory, potentially leading to arbitrary code execution or data corruption. The bug is specific to x86 64 targets and does not affect the AArch64 backend. Affected embedders are recommended to analyze preexisting wasm modules for potential exploitation and consider workarounds to mitigate the issue. **Recommendations** For wasmtime versions prior to 4.0.1: Update to version 4.0.1 or later to fix the erroneous lowering rules in the Cranelift backend. For wasmtime versions prior to 5.0.1: Update to version 5.0.1 or later to fix the erroneous lowering rules in the Cranelift backend. For wasmtime versions prior to 6.0.1: Update to version 6.0.1 or later to fix the erroneous lowering rules in the Cranelift backend. As a temporary workaround, consider using the `Config::static memory maximum size(0)` option to force explicit bounds checking for all accesses to linear memory. Alternatively, use the `Config::static memory guard size(1 << 36)` option to increase the guard pages placed after linear memory, or switch to a non-x86 64 host if possible.

**Name of the Vulnerable Software and Affected Versions** Wasmtime versions prior to 2.0.2 **Description** There is a bug in Wasmtime's C API implementation where the definition of the `wasmtime trap code` does not match its declared signature in the `wasmtime/trap.h` header file. This discrepancy causes the function implementation to perform a 4-byte write into a 1-byte buffer provided by the caller, leading to three zero bytes being written beyond the 1-byte location provided by the caller. This issue affects users of the C API function `wasmtime trap code`, but not users of the `wasmtime` crate. **Recommendations** For versions prior to 2.0.2, upgrade to Wasmtime 2.0.2 to resolve the issue. As a temporary workaround, consider providing a 4-byte buffer casted to a 1-byte buffer when calling `wasmtime trap code`.

**Name of the Vulnerable Software and Affected Versions** Wasmtime versions prior to 2.0.2 **Description** There is a bug in Wasmtime's implementation of its pooling instance allocator where when a linear memory is reused for another instance, the initial heap snapshot of the prior instance can be visible, erroneously to the next instance. This bug occurs when a slot in the pooling allocator previously was used for a module with a heap image, and the next instantiation within that slot does not itself contain a heap image. The bug is highly unlikely to be accidentally triggered and would otherwise require an intentional trigger with a hand-crafted module. In practice, modules must be deliberately crafted to not have an initial heap image to view the contents of a prior image. **Recommendations** To resolve the issue, upgrade to Wasmtime 2.0.2. As a temporary workaround, consider disabling the pooling allocator. Additionally, disabling the `memory-init-cow` feature can mitigate the issue.

**Name of the Vulnerable Software and Affected Versions** Wasmtime versions prior to 2.0.2 **Description** 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 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. **Recommendations** To resolve the issue, upgrade to Wasmtime 2.0.2. As a temporary workaround, consider 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.

**Name of the Vulnerable Software and Affected Versions** Wasmtime versions 0.37.0 through 0.38.1 **Description** There is a bug in Wasmtime's code generator, Cranelift, where functions using reference types may be incorrectly missing metadata required for runtime garbage collection. This means that if a GC happens at runtime, the GC pass will mistakenly think these functions do not have live references to GC'd values, reclaiming them and deallocating them. The function will then subsequently continue to use the values assuming they had not been GC'd, leading later to a use-after-free. This bug was introduced in the migration to the `regalloc2` register allocator that occurred in the Wasmtime 0.37.0 release. **Recommendations** To resolve the issue, upgrade to Wasmtime version 0.38.2. As a temporary workaround, consider disabling the reference types proposal by passing `false` to `wasmtime::Config::wasm reference types`. Alternatively, downgrade to Wasmtime 0.36.0 or prior.

**Name of the Vulnerable Software and Affected Versions** Wasmtime versions prior to 0.38.1 cranelift-codegen versions prior to 0.85.1 **Description** The issue is related to Wasmtime's implementation of the SIMD proposal for WebAssembly on x86 64, which contained two bugs in the instruction lowerings implemented in Cranelift. The bugs were presented in the `i8x16.swizzle` and `select` WebAssembly instructions. The `select` instruction is only affected when the inputs are of `v128` type. The correspondingly affected Cranelift instructions were `swizzle` and `select`. This bug represents an incorrect implementation of the specified semantics of these instructions according to the WebAssembly specification. The impact of this is benign for hosts running WebAssembly but represents possible vulnerabilities within the execution of a guest program. For example, a WebAssembly program could take unintended branches or materialize incorrect values internally, which runs the risk of exposing the program itself to other related vulnerabilities that can occur from miscompilations. **Recommendations** For Wasmtime versions prior to 0.38.1, update to version 0.38.1 or later. For cranelift-codegen versions prior to 0.85.1, update to version 0.85.1 or later. As a temporary workaround, consider disabling the Wasm simd proposal by setting `config.wasm simd(false)`.

**Name of the Vulnerable Software and Affected Versions** Wasmtime versions prior to 0.30.0 **Description** A type confusion vulnerability was discovered in the safe API of `Linker::func *` APIs. This issue occurs when one `Engine` is used to create the `Linker` and then a different `Engine` is used to create a `Store` and then the `Linker` is used to instantiate a module into that `Store`. Cross-`Engine` usage of functions is not supported in Wasmtime and this can result in type confusion of function pointers, resulting in being able to safely call a function with the wrong type. Additionally, there was an invalid free and out-of-bounds read and write bug when running Wasm that uses `externref`s in Wasmtime. The impact of these issues is expected to be relatively small because usage of more-than-one `Engine` in an embedding and usage of `externref` is currently quite rare. **Recommendations** To resolve the issue, upgrade to Wasmtime version 0.30.0. If you cannot upgrade Wasmtime and are using more than one `Engine` in your embedding, use only one `Engine` for the entire program if possible. If using multiple `Engine`s is required, audit the code to ensure that `Linker` is only used with one `Engine`. If you cannot upgrade Wasmtime and are using `externref`s, disable reference types support in Wasmtime by passing `false` to `wasmtime::Config::wasm reference types`.