Impact

Wasmtime's filesystem sandbox implementation on Windows blocks access to special device filenames such as "COM1", "COM2", "LPT0", "LPT1", and so on, however it did not block access to the special device filenames which use superscript digits, such as "COM¹", "COM²", "LPT⁰", "LPT¹", and so on. Untrusted Wasm programs that are given access to any filesystem directory could bypass the sandbox and access devices through those special device filenames with superscript digits, and through them gain access peripheral devices connected to the computer, or network resources mapped to those devices. This can include modems, printers, network printers, and any other device connected to a serial or parallel port, including emulated USB serial ports.

Patches

Patch releases for Wasmtime have been issued as 24.0.2, 25.0.3, and 26.0.1. Users of Wasmtime 23.0.x and prior are recommended to upgrade to one of these patched versions.

Workarounds

There are no known workarounds for this issue. Affected Windows users are recommended to upgrade.

References

- Microsoft's documentation of the special device filenames - ISO-8859-1 - The original PR reporting the issue

Impact

Under certain concurrent event orderings, a wasmtime::Engine's internal type registry was susceptible to double-unregistration bugs due to a race condition, leading to panics and potentially type registry corruption. That registry corruption could, following an additional and particular sequence of concurrent events, lead to violations of WebAssembly's control-flow integrity (CFI) and type safety. Users that do not use wasmtime::Engine across multiple threads are not affected. Users that only create new modules across threads over time are additionally not affected.

Reproducing this bug requires creating and dropping multiple type instances (such as wasmtime::FuncType or wasmtime::ArrayType) concurrently on multiple threads, where all types are associated with the same wasmtime::Engine. Wasm guests cannot trigger this bug. See the "References" section below for a list of Wasmtime types-related APIs that are affected.

Wasmtime maintains an internal registry of types within a wasmtime::Engine and an engine is shareable across threads. Types can be created and referenced through creation of a wasmtime::Module, creation of wasmtime::FuncType, or a number of other APIs where the host creates a function (see "References" below). Each of these cases interacts with an engine to deduplicate type information and manage type indices that are used to implement type checks in WebAssembly's callindirect function, for example. This bug is a race condition in this management where the internal type registry could be corrupted to trigger an assert or contain invalid state.

Wasmtime's internal representation of a type has individual types (e.g. one-per-host-function) maintain a registration count of how many time it's been used. Types additionally have state within an engine behind a read-write lock such as lookup/deduplication information. The race here is a time-of-check versus time-of-use (TOCTOU) bug where one thread atomically decrements a type entry's registration count, observes zero registrations, and then acquires a lock in order to unregister that entry. However, between when this first thread observed the zero-registration count and when it acquires that lock, another thread could perform the following sequence of events: re-register another copy of the type, which deduplicates to that same entry, resurrecting it and incrementing its registration count; then drop the type and decrement its registration count; observe that the registration count is now zero; acquire the type registry lock; and finally unregister the type. Now, when the original thread finally acquires the lock and unregisters the entry, it is the second time this entry has been unregistered.

| Thread A | Thread B | |-----------------------------------|--------------------------------| | acquire(type registry lock) | | | | decref(E) --> 0 | | | blockon(type registry lock) | | register(E') == incref(E) --> 1 | | | release(type registry lock) | | | decref(E) --> 0 | | | acquire(type registry lock) | | | unregister(E) | | | release(type registry lock) | | | | acquire(type registry lock) | | | unregister(E) |

This double-unregistration could then lead to a WebAssembly CFI violation under the following conditions: a new WebAssembly module X was loaded into the engine before the second, buggy unregistration occurs; X defined a function type F that was allocated in the same type registry slot where the original entry was allocated; the second, buggy unregistration incorrectly unregistered F; another new WebAssembly module Y was loaded into the engine; Y defined a function type G, different from F, but which is also allocated in the same type registry slot; a funcref of type G is created, either by the host or by Wasm; that funcref is passed to a WebAssembly instance of module X; that instance performs a callindirect to that funcref; the callindirect's dynamic type check, which preserves CFI, could incorrectly pass in this case, because F and G were assigned the same type registry slot. This would, ultimately, allow calling a function with too many, too few, or wrongly-typed arguments, violating CFI and type safety.

We were not able to reproduce this CFI violation in a vanilla Wasmtime build, although it remains theoretically possible. However, by modifying Wasmtime's source code to make losing the races described above more likely (by disabling certain assertions, inserting panic catches, and adding retry loops in a few places if we did not lose the race) we were able to incorrectly get a funcref to pass a type check that it should have failed, which would allow the CFI violation.

Patches

This bug was originally introduced in Wasmtime 19's development of the WebAssembly GC proposal. This bug affects users who are not using the GC proposal, however, and affects Wasmtime in its default configuration even when the GC proposal is disabled. Wasmtime users using 19.0.0 and after are all affected by this issue. We have released the following Wasmtime versions, all of which have a fix for this bug:

21.0.2 22.0.1 23.0.3 24.0.1 25.0.2

Workarounds

If your application creates and drops Wasmtime types on multiple threads concurrently, there are no known workarounds. Users are encouraged to upgrade to a patched release.

References

The following APIs create or drop types, and therefore are affected by this race condition if performed on multiple threads concurrently and are all associated with the same wasmtime::Engine:

wasmtime::FuncType::new Also reachable from creation of wasmtime::Func Also reachable from wasmtime::Linker::func wasmtime::ArrayType::new wasmtime::StructType::new wasmtime::Func::ty wasmtime::Global::ty wasmtime::Table::ty wasmtime::Extern::ty wasmtime::Export::ty wasmtime::UnknownImportError::ty wasmtime::ImportType::ty wasmtime::ExportType::ty wasmtime::Val::ty wasmtime::Ref::ty wasmtime::AnyRef::ty wasmtime::EqRef::ty wasmtime::ArrayRef::ty wasmtime::StructRef::ty Dropping a wasmtime::FuncType Dropping a wasmtime::ArrayType Dropping a wasmtime::StructType Dropping a wasmtime::ExternType Dropping a wasmtime::GlobalType Dropping a wasmtime::TableType Dropping a wasmtime::ValType Dropping a wasmtime::RefType Dropping a wasmtime::HeapType Dropping a wasmtime::UnknownImportError Dropping a wasmtime::Linker

The change which introduced this bug was #7969

Impact

Wasmtime's implementation of WebAssembly tail calls combined with stack traces can result in a runtime crash in certain WebAssembly modules. The runtime crash may be undefined behavior if Wasmtime was compiled with Rust 1.80 or prior. The runtime crash is a deterministic process abort when Wasmtime is compiled with Rust 1.81 and later.

WebAssembly tail calls are a proposal which relatively recently reached stage 4 in the standardization process. Wasmtime first enabled support for tail calls by default in Wasmtime 21.0.0, although that release contained a bug where it was only on-by-default for some configurations. In Wasmtime 22.0.0 tail calls were enabled by default for all configurations.

The specific crash happens when an exported function in a WebAssembly module (or component) performs a returncall (or returncallindirect or returncallref) to an imported host function which captures a stack trace (for example, the host function raises a trap). In this situation, the stack-walking code previously assumed there was always at least one WebAssembly frame on the stack but with tail calls that is no longer true. With the tail-call proposal it's possible to have an entry trampoline appear as if it directly called the exit trampoline. This situation triggers an internal assert in the stack-walking code which raises a Rust panic!().

When Wasmtime is compiled with Rust versions 1.80 and prior this means that an extern "C" function in Rust is raising a panic!(). This is technically undefined behavior and typically manifests as a process abort when the unwinder fails to unwind Cranelift-generated frames. When Wasmtime is compiled with Rust versions 1.81 and later this panic becomes a deterministic process abort.

Overall the impact of this issue is that this 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.

This issue was discovered by routine fuzzing performed by the Wasmtime project via Google's OSS-Fuzz infrastructure. We have no evidence that it has ever been exploited by an attacker in the wild.

Patches

All versions of Wasmtime which have tail calls enabled by default have been patched:

21.0.x - patched in 21.0.2 22.0.x - patched in 22.0.1 23.0.x - patched in 23.0.3 24.0.x - patched in 24.0.1 25.0.x - patched in 25.0.2

Wasmtime versions from 12.0.x (the first release with experimental tail call support) to 20.0.x (the last release with tail-calls off-by-default) have support for tail calls but the support is disabled by default. These versions are not affected in their default configurations, but users who explicitly enabled tail call support will need to either disable tail call support or upgrade to a patched version of Wasmtime.

Workarounds

The main workaround for this issue is to disable tail support for tail calls in Wasmtime, for example with Config::wasmtailcall(false). Users are otherwise encouraged to upgrade to patched versions.

References

Wasmtime's initial implementation of tail calls Enabling of tail calls in 21.0.0 Fully enabling tail calls in 22.0.0 The WebAssembly's tail-call proposal