Fitzgen

**Name of the Vulnerable Software and Affected Versions** Wasmtime versions 19.0.0 through 20.0.0 Wasmtime versions 21.0.0 through 21.0.1 Wasmtime versions 22.0.0 Wasmtime versions 23.0.0 through 23.0.2 Wasmtime versions 24.0.0 Wasmtime versions 25.0.0 through 25.0.1 **Description** A race condition in Wasmtime's internal type registry can lead to panics and potentially type registry corruption under certain concurrent event orderings. This corruption could result in violations of WebAssembly's control-flow integrity (CFI) and type safety. Users that do not use `wasmtime::Engine` across multiple threads are not affected. The issue arises from a time-of-check versus time-of-use (TOCTOU) bug where one thread atomically decrements a type entry's registration count and then acquires a lock to unregister that entry, but another thread could re-register the type, resurrecting it, before the first thread acquires the lock. This double-unregistration could lead to a WebAssembly CFI violation if a new WebAssembly module is loaded into the engine before the second unregistration occurs. **Recommendations** For Wasmtime versions 19.0.0 through 20.0.0, upgrade to version 21.0.2 or later. For Wasmtime versions 21.0.0 through 21.0.1, upgrade to version 21.0.2 or later. For Wasmtime versions 22.0.0, upgrade to version 22.0.1 or later. For Wasmtime versions 23.0.0 through 23.0.2, upgrade to version 23.0.3 or later. For Wasmtime versions 24.0.0, upgrade to version 24.0.1 or later. For Wasmtime versions 25.0.0 through 25.0.1, upgrade to version 25.0.2 or later. As a temporary workaround, consider avoiding the creation and dropping of Wasmtime types on multiple threads concurrently.

**Name of the Vulnerable Software and Affected Versions** Wasmtime versions 0.19.0 through 0.29.0 **Description** The issue is related to a use-after-free bug when passing `externref`s from the host to guest Wasm content. To trigger the bug, multiple `externref`s must be passed from the host to a Wasm instance at the same time. The bug can be triggered by passing multiple `externref`s as arguments from host code to a Wasm function or returning multiple `externref`s to Wasm from a multi-value return function defined in the host. If Wasmtime's `VMExternRefActivationsTable` becomes filled to capacity after passing the first `externref` in, then passing in the second `externref` could trigger a garbage collection. However, the first `externref` is not rooted until control is passed to Wasm, and therefore could be reclaimed by the collector if nothing else was holding a reference to it or otherwise keeping it alive. Then, when control was passed to Wasm after the garbage collection, Wasm could use the first `externref`, which at this point has already been freed. Additionally, there is an invalid free and out-of-bounds read and write bug when running Wasm that uses `externref`s in Wasmtime. The bug can be triggered when Wasmtime is running Wasm that uses `externref`s, the host creates non-null `externrefs`, Wasmtime performs a garbage collection, and there has to be a Wasm frame on the stack that is at a GC safepoint where there are no live references at this safepoint, and there is a safepoint with live references earlier in this frame's function. The estimated impact of these bugs is relatively small because usage of `externref` is currently quite rare. **Recommendations** For Wasmtime versions 0.19.0 through 0.29.0, upgrade to Wasmtime 0.30.0 to fix the bug. If you cannot upgrade Wasmtime yet, you can avoid the bug by disabling reference types support in Wasmtime by passing `false` to `wasmtime::Config::wasm reference types`. If you are using more than one `Engine` in your embedding, it's recommended to instead use only one `Engine` for the entire program if possible. An `Engine` is designed to be a globally shared resource that is suitable to have only one for the lifetime of an entire process. If using multiple `Engine`s is required, then code should be audited to ensure that `Linker` is only used with one `Engine`.

**Name of the Vulnerable Software and Affected Versions** Wasmtime versions 0.19.0 through 0.29.0 Wasmtime versions 0.26.0 through 0.29.0 **Description** There is a memory unsoundness vulnerability in Wasmtime, which can be triggered when running Wasm that uses `externref`s. This can result in an invalid free and out-of-bounds read and write bug. The vulnerability can be exploited when the host creates non-null `externrefs`, Wasmtime performs a garbage collection, and there is a Wasm frame on the stack that is at a GC safepoint with no live references. Additionally, there is a type confusion vulnerability when using the `Linker` API with multiple `Engine` values, which can result in calling a function with the wrong type. The estimated impact of these bugs is relatively small due to the rare usage of `externref`s. **Recommendations** For Wasmtime versions 0.19.0 through 0.29.0, upgrade to Wasmtime version 0.30.0. For Wasmtime versions 0.26.0 through 0.29.0, as a temporary workaround, consider disabling the reference types proposal by passing `false` to `wasmtime::Config::wasm reference types` until a patch is available. If using multiple `Engine`s is required, audit the code to ensure that `Linker` is only used with one `Engine`.