Summary

When running with the Cranelift compiler backend on an aarch64 target, Wasmtime can compile a Wasm module with more than ~256k targets on one brtable instruction in a way that results in an incorrect conditional branch target. This conditional branch could then jump to arbitrary other code (at an user-controlled offset), leading to arbitrary sandbox escapes.

Impact

Any Wasmtime engine running on aarch64 with default settings can be forced to jump to arbitrary code by a user-controlled Wasm module. All versions of Wasmtime/Cranelift that support aarch64, since the initial release of that support in 2020 (before Wasmtime v1.0), are affected.

Patches

Wasmtime v36.0.19, v48.0.7, and v49.0.4 have been released which all fix this issue.

Summary

In Wasmtime prior to v43, the Cranelift compiler backend bit-packs its SSA value indices in a way that can result in silent overflow in release builds, and result in incorrect value references in the IR resulting in arbitrary miscompilation. A very large Wasm function body, or one that is specially crafted to use many SSA values, can use this to force type-confusion or other arbitrary side-effects and escape the sandbox.

Cranelift was changed in Wasmtime v43 to use a full u32 index, with checks if that limit is exceeded, and so is no longer susceptible to this bug.

Impact

A Wasmtime engine with default settings (using the Cranelift backend) on any architecture/platform could experience a sandbox escape from a specially-crafted Wasm module.

Patches

Wasmtime v36.0.19 has been released which fixes this issue.

Wasmtime 39.0.0 before 48.0.4 and 49.0.0 before 49.0.2 contains a stack buffer overflow vulnerability that allows malicious guests to write ~16KB to the native stack via unvalidated async callback result types. Attackers can supply components with mistyped component-model-async callback functions to overwrite return addresses, crashing the host or escaping the sandbox.

This is an entry in the RustSec database for the Wasmtime security advisory located at https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-vqjp-4c8c-hfgg For more information see the GitHub-hosted security advisory.

WebAssembly Micro Runtime (WAMR) is a lightweight standalone WebAssembly (Wasm) runtime. Prior to 2.4.5, the two-pass fast interpreter loader in core/iwasm/interpreter/wasmloader.c can make inconsistent constant-table decisions between the sizing pass and the emitting pass. After duplicate constants inflate the first pass beyond the constant-slot limit, wasmloadergetconstoffset emits later constants inline, but the between-pass sort and deduplication reduces the table so the second pass can choose table references and cause reserveblockret to emit additional copy operands that were not included in codecompiledpeaksize. A crafted module can therefore make the second pass write partially attacker-controlled compiled-code data beyond the heap buffer allocated from the first pass's size calculation during wasmruntimeload, before guest code executes. This can corrupt host heap metadata and deterministically crash the process, causing denial of service; further consequences depend on the host application's heap layout. Builds using WAMRBUILDFASTINTERP=1 are affected; disabling the fast interpreter avoids the vulnerable loader. This issue is fixed in version 2.4.5.

An out-of-bound memory read vulnerability was discovered in Bytecode Alliance wasm-micro-runtime v2.0.0 which allows a remote attacker to cause a denial of service via the "blocktypegetarity" function in core/iwasm/interpreter/wasm.h.

Wasmtime 47.0.0 before 48.0.4 and 49.0.0 before 49.0.2 contains a missing GC rooting vulnerability that leaves references live across trycall unrooted when compiling Wasm modules. Attackers can supply Wasm modules whose callee triggers garbage collection, leaving stale or dangling references that cause GC heap corruption or incorrect execution.

Wasmtime 46.0.0 before 46.0.3 and 47.0.0 before 47.0.4 contains an uncontrolled resource allocation vulnerability in its WASIp3 implementation that buffers guest-specified-length writes on the host without limit. Malicious guests can offer large buffers to WASIp3 file or HTTP write streams, causing the host to copy and buffer all bytes, bounded only by guest linear memory, exhausting host memory.

Wasmtime 47.0.0 before 48.0.3 and 49.0.0 before 49.0.1 contains a fuel accounting flaw in Cranelift-compiled callref and trytable catch paths. Malicious guests can reset consumed fuel after calls to run exponentially long on linear fuel, evading timeouts and periodic yields for denial of service.

Wasmtime before 36.0.16, 37.0.0 before 48.0.3, and 49.0.0 before 49.0.1 contains a denial of service vulnerability in wasmtime-wasi that allows guest WASI programs to panic the host via overflowing filesystem timestamps. Attackers can pass atim or mtim values whose sub-second field overflows the seconds field to pathfilestatsettimes, fdfilestatsettimes, set-times, or set-times-at, crashing the host.

wasmtime-wasi-http in Wasmtime before 36.0.16, 37.0.0 before 48.0.3, and 49.0.0 before 49.0.1 does not enforce the wasi:io/streams check-write allowance for WASIp2 outgoing HTTP bodies, so oversized writes succeed instead of trapping. A malicious guest can pass large buffers to write on outgoing-body resources, holding host allocations for the store's lifetime and exhausting host memory.

Wasmtime 46.0.0 before 48.0.4 and 49.0.0 before 49.0.2 contains a denial of service vulnerability in the wasmtime-wasi WASIp3 implementation that allows guests to abort the Unix host process. Guests with mutable preopened directory access can call set-times or set-times-at with negative seconds timestamps before the epoch, triggering an assertion failure that crashes the host.

Wasmtime before 36.0.16, 37.0.0 before 48.0.3, and 49.0.0 before 49.0.1 contains a denial of service vulnerability in wasmtime-wasi that allows guest WASI programs to panic the host via overflowing filesystem timestamps. Attackers can pass atim or mtim values whose sub-second field overflows the seconds field to pathfilestatsettimes, fdfilestatsettimes, set-times, or set-times-at, crashing the host.

WebAssembly Micro Runtime (WAMR) is a lightweight standalone WebAssembly (Wasm) runtime. Prior to 2.4.5, loadinitexpr in core/iwasm/interpreter/wasmloader.c accepts a non-reference heap-type byte for ref.null when WASMENABLEGC=0, while the local WASMValue curvalue union is not zero-initialized and setting refindex writes only part of it. A crafted module can declare an i64, f64, or v128 global initialized through the invalid ref.null form, causing pushconstexprstack and the later global initialization path to copy uninitialized host-stack bytes into a value readable by the guest. The classic and fast interpreters are affected in the default no-GC configuration; the GC-enabled path validates heap types. The disclosure is four bytes for i64 or f64 globals and up to twelve bytes for each v128 global. This issue is fixed in version 2.4.5.

WebAssembly Micro Runtime (WAMR) is a lightweight standalone WebAssembly (Wasm) runtime. Prior to 2.4.5, loadinitexpr in core/iwasm/interpreter/wasmloader.c accepts a non-reference heap-type byte for ref.null when WASMENABLEGC=0, while the local WASMValue curvalue union is not zero-initialized and setting refindex writes only part of it. A crafted module can declare an i64, f64, or v128 global initialized through the invalid ref.null form, causing pushconstexprstack and the later global initialization path to copy uninitialized host-stack bytes into a value readable by the guest. The classic and fast interpreters are affected in the default no-GC configuration; the GC-enabled path validates heap types. The disclosure is four bytes for i64 or f64 globals and up to twelve bytes for each v128 global. This issue is fixed in version 2.4.5.

Wasmtime 47.0.0 before 48.0.4 and 49.0.0 before 49.0.2 contains a missing GC rooting vulnerability that leaves references live across trycall unrooted when compiling Wasm modules. Attackers can supply Wasm modules whose callee triggers garbage collection, leaving stale or dangling references that cause GC heap corruption or incorrect execution.

Wasmtime 46.0.0 before 46.0.3 and 47.0.0 before 47.0.4 contains an uncontrolled resource allocation vulnerability in its WASIp3 implementation that buffers guest-specified-length writes on the host without limit. Malicious guests can offer large buffers to WASIp3 file or HTTP write streams, causing the host to copy and buffer all bytes, bounded only by guest linear memory, exhausting host memory.

Wasmtime 46.0.0 before 46.0.3 and 47.0.0 before 47.0.4 contains an uncontrolled resource allocation vulnerability in its WASIp3 implementation that buffers guest-specified-length writes on the host without limit. Malicious guests can offer large buffers to WASIp3 file or HTTP write streams, causing the host to copy and buffer all bytes, bounded only by guest linear memory, exhausting host memory.

A heap buffer overflow vulnerability was discovered in Bytecode Alliance wasm-micro-runtime v2.0.0 which allows a remote attacker to cause at least a denial of service via the "wasmloadercheckbr" function in core/iwasm/interpreter/wasmloader.c.

Wasmtime 47.0.0 before 48.0.4 and 49.0.0 before 49.0.2 contains an improper validation vulnerability that accepts components whose core modules import WebAssembly tags with a subtype of the original type. Malicious guests can mis-type exception object payloads to corrupt the GC heap, causing Wasmtime to panic when the exceptions proposal is enabled.

Wasmtime before 36.0.17, 37.0.0 before 48.0.4, and 49.0.0 before 49.0.2 contains an unbounded memory allocation in the wasmtime-wasi WASIp2 write-zeroes method of SinkOutputStream, the default stream used when stdout/stderr are not configured. A malicious WebAssembly guest can request huge zero-filled writes, exhausting host memory and causing denial of service.

Wasmtime 46.0.0 before 48.0.4 and 49.0.0 before 49.0.2 contains a denial-of-service vulnerability in its wasi:http implementation that allows guests to panic the host. Guests can specify a zero between-bytes-timeout request option, which is forwarded directly to a Tokio API that panics, crashing the host embedding.

Wasmtime 47.0.0 before 48.0.4 and 49.0.0 before 49.0.2 contains an improper validation vulnerability that accepts components whose core modules import WebAssembly tags with a subtype of the original type. Malicious guests can mis-type exception object payloads to corrupt the GC heap, causing Wasmtime to panic when the exceptions proposal is enabled.

Wasmtime 47.0.0 before 48.0.4 and 49.0.0 before 49.0.2 contains an improper validation vulnerability that accepts components whose core modules import WebAssembly tags with a subtype of the original type. Malicious guests can mis-type exception object payloads to corrupt the GC heap, causing Wasmtime to panic when the exceptions proposal is enabled.

Summary

Wasmtime may panic when the host lowers a component model stream or future into a guest, if the host created that stream or future with one payload type and the guest expects a different one. This can happen when an embedder creates a stream or future, passes it through a guest, receives it back under a type-erased type such as StreamAny or FutureAny, and then passes it to a guest function with a different payload type.

GHSA-63h4-6cx9-pjfj is a related advisory also fixing issues within this area, and this advisory is being issued for portions of Wasmtime that were not fixed as part of that advisory.

Impact

This affects embedders that do all of the following:

1. Create streams or futures on the host with StreamReader::new or FutureReader::new 2. Pass them to guest code and receive them back as StreamAny, FutureAny, Val::Stream/Val::Future, or a typed reader whose payload is one of these. 3. Pass them on to a guest function whose stream or future payload type differs from the type the host created them with.

A guest can cause the mismatch in step 3 when it controls the types of the functions it exports or of the values it returns. In that case a malicious guest can make the host panic, a denial of service. Embedders that only use statically typed StreamReader<T>/FutureReader<T> with concrete payload types throughout, or that never pass streams or futures they created through a guest and back, are not affected.

Wasmtime before 36.0.17, 37.0.0 before 48.0.4, and 49.0.0 before 49.0.2 contains a denial of service vulnerability in the wasmtime-wasi WASI preview 0 polloneoff adapter, which performs O(n) host work per subscription without consuming or checking fuel. Malicious guest modules can pass many subscriptions to force long-running host computation that ignores configured fuel limits.

Wasmtime before 36.0.17, 37.0.0 before 48.0.4, and 49.0.0 before 49.0.2 contains an information disclosure vulnerability in the WASIp1 fdreaddir implementation that copies uninitialized struct padding into guest memory. Guests with a preopened directory can list entries to receive three bytes of leftover host stack or heap memory per directory entry.

Impact

Wasmtime's Rust embedder API contains an unsound interaction where a WebAssembly shared linear memory could be viewed as a type which provides safe access to the host (Rust) to the contents of the linear memory. This is not sound for shared linear memories, which could be modified in parallel, and this could lead to a data race in the host.

Wasmtime has a wasmtime::Memory type which represents linear memories in a WebAssembly module. Wasmtime also has wasmtime::SharedMemory, however, which represents shared linear memories introduced in the WebAssembly threads proposal. The API of SharedMemory does not provide accessors which return &[u8] in Rust, for example, as that's not a sound type signature when other threads could be modifying memory. The wasmtime::Memory type, however, does provide this API as it's intended to be used with non-shared memories where static knowledge is available that no concurrent or parallel reads or writes are happening. This means that it's not sound to represent a shared linear memory with wasmtime::Memory and it must instead be represented with wasmtime::SharedMemory.

There were two different, erroneous, methods of creating a wasmtime::Memory which represents a shared memory however:

1. The wasmtime::Memory::new constructor takes a MemoryType which could be shared. This function did not properly reject shared memory types and require usage of SharedMemory::new instead. 2. Capturing a core dump with WebAssembly would expose all linear memories a wasmtime::Memory. This means that a core dump would perform an unsynchronized read of shared linear memory, possibly leading to data races.

This is a bug in Wasmtime's safe Rust API. It should not be possible to cause unsoundness with Wasmtime's embedding API if unsafe is not used. Embeddings which do not use the wasm threads proposal nor created shared memories nor actually share shared memories across threads are unaffected. Only if shared memories are created across threads might an embedding be affected.

Patches

Patch releases have been issued for all supported versions of Wasmtime, notably: 24.0.5, 36.0.3, 37.0.3, and 38.0.4. These releases reject creation of shared memories via Memory::new and shared memories are now excluded from core dumps.

Workarounds

Embeddings affected by this issue should use SharedMemory::new instead of Memory::new to create shared memories. Affected embeddings should also disable core dumps if they are unable to upgrade. Note that core dumps are disabled by default but the wasm threads proposal (and shared memory) is enabled by default. It's recommended to upgrade to a patched version of Wasmtime, however.

Wasmtime before 24.0.12, 25.0.0 before 36.0.13, 37.0.0 before 46.0.2, and 47.0.0 before 47.0.3 contains a type confusion vulnerability because several Store APIs fail to validate that objects belong to the Store's Engine. Embedders mixing objects between Engines via Instance::new, StructRefPre::new, or Tag::new can trigger trampoline signature mismatches causing out-of-bounds stack writes, GC heap corruption, or panics.

Wasmtime before 36.0.16, 37.0.0 before 48.0.3, and 49.0.0 before 49.0.1 does not adequately account for host allocations when lifting guest values through the dynamically-typed Val API, bypassing the hostcall fuel limit. A malicious WebAssembly guest can return crafted values that allocate at least ~100x more host memory than tracked, causing denial of service.