### 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: ```rust use wasmtime::{Linker, Result, Store}; fn clone_linker<T>(linker: &Linker<T>, store: &mut Store<T>) -> Result<Linker<T>> { let mut cloned = Linker::new(); for (module, name, item) in linker.iter(store) { cloned.define(module, name, item)?; } Ok(cloned) } ``` ### References This bug was introduced during an internal refactoring that was part of our efforts to [robustly handle allocation failure in Wasmtime](https://github.com/bytecodealliance/wasmtime/issues/12069). This refactoring introduced an string-interning pool which had an unsound `TryClone`[^try-clone] implementation. [^try-clone]: [The `TryClone` trait](https://github.com/bytecodealliance/wasmtime/blob/33e8b3d955697587b23cf39d87fbcbdb4d26b0c9/crates/core/src/alloc/try_clone.rs#L5-L17) is our version of the Rust standard library's `Clone` trait that allows for returning `OutOfMemory` errors. * 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
### 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: ```rust use wasmtime::{Linker, Result, Store}; fn clone_linker<T>(linker: &Linker<T>, store: &mut Store<T>) -> Result<Linker<T>> { let mut cloned = Linker::new(); for (module, name, item) in linker.iter(store) { cloned.define(module, name, item)?; } Ok(cloned) } ``` ### References This bug was introduced during an internal refactoring that was part of our efforts to [robustly handle allocation failure in Wasmtime](https://github.com/bytecodealliance/wasmtime/issues/12069). This refactoring introduced an string-interning pool which had an unsound `TryClone`[^try-clone] implementation. [^try-clone]: [The `TryClone` trait](https://github.com/bytecodealliance/wasmtime/blob/33e8b3d955697587b23cf39d87fbcbdb4d26b0c9/crates/core/src/alloc/try_clone.rs#L5-L17) is our version of the Rust standard library's `Clone` trait that allows for returning `OutOfMemory` errors. * 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
Update wasmtime to 43.0.1 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanWasmtime has use-after-free bug after cloning `wasmtime::Linker` affects wasmtime (rust). Severity is low. ### 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: ```rust use wasmtime::{Linker, Result, Store}; fn clone_linker<T>(linker: &Linker<T>, store: &mut Store<T>) -> Result<Linker<T>> { let mut cloned = Linker::new(); for (module, name, item) in linker.iter(store) { cloned.define(module, name, item)?; } Ok(cloned) } ``` ### References This bug was introduced during an internal refactoring that was part of our efforts to [robustly handle allocation failure in Wasmtime](https://github.com/bytecodealliance/wasmtime/issues/12069). This refactoring introduced an string-interning pool which had an unsound `TryClone`[^try-clone] implementation. [^try-clone]: [The `TryClone` trait](https://github.com/bytecodealliance/wasmtime/blob/33e8b3d955697587b23cf39d87fbcbdb4d26b0c9/crates/core/src/alloc/try_clone.rs#L5-L17) is our version of the Rust standard library's `Clone` trait that allows for returning `OutOfMemory` errors. * 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
AI coding agents often install or upgrade packages automatically in rust. A low vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| wasmtimerust | =43.0.0 | 43.0.1 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate wasmtime to 43.0.1 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanWasmtime has use-after-free bug after cloning `wasmtime::Linker` affects wasmtime (rust). Severity is low. ### 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: ```rust use wasmtime::{Linker, Result, Store}; fn clone_linker<T>(linker: &Linker<T>, store: &mut Store<T>) -> Result<Linker<T>> { let mut cloned = Linker::new(); for (module, name, item) in linker.iter(store) { cloned.define(module, name, item)?; } Ok(cloned) } ``` ### References This bug was introduced during an internal refactoring that was part of our efforts to [robustly handle allocation failure in Wasmtime](https://github.com/bytecodealliance/wasmtime/issues/12069). This refactoring introduced an string-interning pool which had an unsound `TryClone`[^try-clone] implementation. [^try-clone]: [The `TryClone` trait](https://github.com/bytecodealliance/wasmtime/blob/33e8b3d955697587b23cf39d87fbcbdb4d26b0c9/crates/core/src/alloc/try_clone.rs#L5-L17) is our version of the Rust standard library's `Clone` trait that allows for returning `OutOfMemory` errors. * 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
AI coding agents often install or upgrade packages automatically in rust. A low vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| wasmtimerust | =43.0.0 | 43.0.1 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard