Alexcrichton

The `wasmtime-wasi` component re-appends a trailing slash to rename source paths. On macOS and FreeBSD hosts, this causes the `renameat()` function to follow directory symlinks. A guest with sandbox write access can exploit this by renaming a relative symlink, such as `up/`, to move host directories into the sandbox, enabling unauthorized read and write access to those directories.

A resource leak exists in the native implementation of WASIp1 within the `fd renumber()` function. The issue occurs because the file descriptor being renumbered is not properly closed; the implementation updates the WASIp1 descriptor table but fails to update the host's underlying descriptor table. Consequently, while the operation appears correct to the guest, resources are leaked on the host and are only reclaimed when the corresponding Store is destroyed. An attacker can repeatedly call `fd renumber()` in a loop to exhaust host resources and file descriptors. This issue only affects runtimes that load core WebAssembly modules, expose `fd renumber()`, and allow the acquisition of file descriptors, such as through file opening operations.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.