GHSA-hfr4-7c6c-48w2

Описание

Impact

In version 43.0.0 of the wasmtime crate, cloning a wasmtime::Linker is unsound and can result in use-after-free bugs.

This bug is not controllable by guest Wasm programs. It can only be triggered by a specific sequence of embedder API calls made by the host.

The typical symptom of this use-after-free bug is a segfault. It does not enable heap corruption or data leakage.

If you are using the wasmtime CLI, rather than the embedding API, you are not affected. If you are using the embedding API but are not calling wasmtime::Linker's Clone implementation, you are not affected.

Specifically, the following steps must occur to trigger the bug:

• Clone a wasmtime::Linker
• Drop the original linker instance
• Use the new, cloned linker instance, resulting in a use-after-free

Patches

This bug has been patched in Wasmtime version 43.0.1

Workarounds

Wasmtime embedders are highly encouraged to upgrade their wasmtime crate dependency.

If upgrading is not an option, or as a temporary workaround before upgrading, you can avoid this bug by not cloning wasmtime::Linker and instead creating a new, empty wasmtime::Linker and manually reregistering the host APIs from the original linker:

References

This bug was introduced during an internal refactoring that was part of our efforts to robustly handle allocation failure in Wasmtime. This refactoring introduced an string-interning pool which had an unsound TryClone¹ implementation.

• The StringPool was introduced in https://github.com/bytecodealliance/wasmtime/pull/12536, at which time the bug in TryClone for StringPool was already present, although this code path was not yet used anywhere.
• wasmtime::Linker was refactored to internally use StringPool in https://github.com/bytecodealliance/wasmtime/pull/12537, at which time the buggy code path became accessible.
• This bug was originally reported to the Wasmtime maintainers as https://github.com/bytecodealliance/wasmtime/pull/12906