CVE-2021-39219
published 2021-09-17CVE-2021-39219: Wasmtime is an open source runtime for WebAssembly & WASI. Wasmtime before version 0.30.0 is affected by a type confusion vulnerability. As a Rust library the…
PriorityP429medium6.3CVSS 3.1
AVLACHPRLUINSUCNIHAH
EPSS
0.29%
21.1th percentile
Wasmtime is an open source runtime for WebAssembly & WASI. Wasmtime before version 0.30.0 is affected by a type confusion vulnerability. As a Rust library the `wasmtime` crate clearly marks which functions are safe and which are `unsafe`, guaranteeing that if consumers never use `unsafe` then it should not be possible to have memory unsafety issues in their embeddings of Wasmtime. An issue was discovered in the safe API of `Linker::func_*` APIs. These APIs were previously not sound when one `Engine` was used to create the `Linker` and then a different `Engine` was used to create a `Store` and then the `Linker` was 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. Triggering this bug requires using at least two `Engine` values in an embedding and then additionally using two different values with a `Linker` (one at the creation time of the `Linker` and another when instantiating a module with the `Linker`). It's expected that usage of more-than-one `Engine` in an embedding is relatively rare since an `Engine` is intended to be a globally shared resource, so the expectation is that the impact of this issue is relatively small. The fix implemented is to change this behavior to `panic!()` in Rust instead of silently allowing it. Using different `Engine` instances with a `Linker` is a programmer bug that `wasmtime` catches at runtime. This bug has been patched and users should upgrade to Wasmtime version 0.30.0. If you cannot upgrade Wasmtime and are using more than one `Engine` in your embedding it's recommended to instead use only one `Engine` for the entire program if possible. An `Engine` is designed to be a globally shared resource that is suitable to have only one for the lifetime of an entire process. If using multiple `Engine`s is required then code should be audited to ensur
Affected
13 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| bytecodealliance | wasmtime | < 0.30.0 | 0.30.0 |
| bytecodealliance | wasmtime | <= 0.29.0 | — |
| bytecodealliance | wasmtime | >= 0 < 101998733b74624cbd348a2366d05760b40181f3 | 101998733b74624cbd348a2366d05760b40181f3 |
| bytecodealliance | wasmtime | >= 0 < 0.30.0 | 0.30.0 |
| bytecodealliance | wasmtime | >= 0 < 398a73f0dd862dbe703212ebae8e34036a18c11c | 398a73f0dd862dbe703212ebae8e34036a18c11c |
| bytecodealliance | wasmtime | >= 0 < b39f087414f27ae40c44449ed5d1154e03449bff | b39f087414f27ae40c44449ed5d1154e03449bff |
| bytecodealliance | wasmtime | >= 0 < 0.30.0 | 0.30.0 |
| bytecodealliance | wasmtime | >= 0.0.0-0 < 0.30.0 | 0.30.0 |
| bytecodealliance | wasmtime | >= 0.26.0 < 0.30.0 | 0.30.0 |
| bytecodealliance | wasmtime | >= 0.26.0 < 0.30.0 | 0.30.0 |
| debian | rust-wasmtime | — | — |
| fedoraproject | fedora | — | — |
| fedoraproject | fedora | — | — |
CVSS provenance
nvdv3.16.3MEDIUMCVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H
nvdv2.03.3LOWAV:L/AC:M/Au:N/C:N/I:P/A:P
vendor_debian6.3LOW
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
GHSA
Wrong type for `Linker`-define functions when used across two `Engine`s
ghsa·2021-09-20
CVE-2021-39219 [MEDIUM] CWE-843 Wrong type for `Linker`-define functions when used across two `Engine`s
Wrong type for `Linker`-define functions when used across two `Engine`s
### Impact
As a Rust library the `wasmtime` crate clearly marks which functions are safe and which are `unsafe`, guaranteeing that if consumers never use `unsafe` then it should not be possible to have memory unsafety issues in their embeddings of Wasmtime. An issue was discovered in the safe API of `Linker::func_*` APIs. These APIs were previously not sound when one `Engine` was used to create the `Linker` and then a different `Engine` was used to create a `Store` and then the `Linker` was 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
OSV
Out-of-bounds read/write and invalid free with `externref`s and GC safepoints in Wasmtime
osv·2021-09-20
CVE-2021-39216 [MEDIUM] Out-of-bounds read/write and invalid free with `externref`s and GC safepoints in Wasmtime
Out-of-bounds read/write and invalid free with `externref`s and GC safepoints in Wasmtime
### Impact
There was an invalid free and out-of-bounds read and write bug when running Wasm that uses `externref`s in Wasmtime.
To trigger this bug, Wasmtime needs to be running Wasm that uses `externref`s, the host creates non-null `externrefs`, Wasmtime performs a garbage collection (GC), and there has to be a Wasm frame on the stack that is at a GC safepoint where
* there are no live references at this safepoint, and
* there is a safepoint with live references earlier in this frame's function.
Under this scenario, Wasmtime would incorrectly use the GC stack map for the safepoint from earlier in the function instead of the empty safepoint. This would result in Wasmtime treating arbitrary stack
OSV
Use after free passing `externref`s to Wasm in Wasmtime
osv·2021-09-20
CVE-2021-39216 [MEDIUM] Use after free passing `externref`s to Wasm in Wasmtime
Use after free passing `externref`s to Wasm in Wasmtime
### Impact
There was a use-after-free bug when passing `externref`s from the host to guest Wasm content.
To trigger the bug, you have to explicitly pass multiple `externref`s from the host to a Wasm instance at the same time, either by
* passing multiple `externref`s as arguments from host code to a Wasm function,
* or returning multiple `externref`s to Wasm from a multi-value return function defined in the host.
If you do not have host code that matches one of these shapes, then you are not impacted.
If Wasmtime's [`VMExternRefActivationsTable`](https://github.com/bytecodealliance/wasmtime/blob/37c094faf53f1b356aab3c79d451395e4f7edb34/crates/runtime/src/externref.rs#L493) became filled to capacity after passing the first `exter
OSV
Wrong type for `Linker`-define functions when used across two `Engine`s
osv·2021-09-20
CVE-2021-39216 [MEDIUM] Wrong type for `Linker`-define functions when used across two `Engine`s
Wrong type for `Linker`-define functions when used across two `Engine`s
### Impact
As a Rust library the `wasmtime` crate clearly marks which functions are safe and which are `unsafe`, guaranteeing that if consumers never use `unsafe` then it should not be possible to have memory unsafety issues in their embeddings of Wasmtime. An issue was discovered in the safe API of `Linker::func_*` APIs. These APIs were previously not sound when one `Engine` was used to create the `Linker` and then a different `Engine` was used to create a `Store` and then the `Linker` was 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
OSV
Multiple Vulnerabilities in Wasmtime
osv·2021-09-17
CVE-2021-39216 Multiple Vulnerabilities in Wasmtime
Multiple Vulnerabilities in Wasmtime
* [Use after free passing `externref`s to Wasm in
Wasmtime](https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-v4cp-h94r-m7xf)
* [Out-of-bounds read/write and invalid free with `externref`s and GC safepoints
in
Wasmtime](https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-4873-36h9-wv49)
* [Wrong type for `Linker`-define functions when used across two
`Engine`s](https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-q879-9g95-56mx)
OSV
CVE-2021-39216: Wasmtime is an open source runtime for WebAssembly & WASI
osv·2021-09-17
CVE-2021-39216 CVE-2021-39216: Wasmtime is an open source runtime for WebAssembly & WASI
Wasmtime is an open source runtime for WebAssembly & WASI. In Wasmtime from version 0.19.0 and before version 0.30.0 there was a use-after-free bug when passing `externref`s from the host to guest Wasm content. To trigger the bug, you have to explicitly pass multiple `externref`s from the host to a Wasm instance at the same time, either by passing multiple `externref`s as arguments from host code to a Wasm function, or returning multiple `externref`s to Wasm from a multi-value return function defined in the host. If you do not have host code that matches one of these shapes, then you are not impacted. If Wasmtime's `VMExternRefActivationsTable` became filled to capacity after passing the first `externref` in, then passing in the second `externref` could trigger a garbage collection. Howeve
OSV
CVE-2021-39216: Wasmtime is an open source runtime for WebAssembly & WASI
osv·2021-09-17
CVE-2021-39216 CVE-2021-39216: Wasmtime is an open source runtime for WebAssembly & WASI
Wasmtime is an open source runtime for WebAssembly & WASI. In Wasmtime from version 0.26.0 and before version 0.30.0 is affected by a memory unsoundness vulnerability. There was an invalid free and out-of-bounds read and write bug when running Wasm that uses `externref`s in Wasmtime. To trigger this bug, Wasmtime needs to be running Wasm that uses `externref`s, the host creates non-null `externrefs`, Wasmtime performs a garbage collection (GC), and there has to be a Wasm frame on the stack that is at a GC safepoint where there are no live references at this safepoint, and there is a safepoint with live references earlier in this frame's function. Under this scenario, Wasmtime would incorrectly use the GC stack map for the safepoint from earlier in the function instead of the empty safepoin
OSV
CVE-2021-39216: Wasmtime is an open source runtime for WebAssembly & WASI
osv·2021-09-17
CVE-2021-39216 CVE-2021-39216: Wasmtime is an open source runtime for WebAssembly & WASI
Wasmtime is an open source runtime for WebAssembly & WASI. Wasmtime before version 0.30.0 is affected by a type confusion vulnerability. As a Rust library the `wasmtime` crate clearly marks which functions are safe and which are `unsafe`, guaranteeing that if consumers never use `unsafe` then it should not be possible to have memory unsafety issues in their embeddings of Wasmtime. An issue was discovered in the safe API of `Linker::func_*` APIs. These APIs were previously not sound when one `Engine` was used to create the `Linker` and then a different `Engine` was used to create a `Store` and then the `Linker` was 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, resulti
Debian
CVE-2021-39219: rust-wasmtime - Wasmtime is an open source runtime for WebAssembly & WASI. Wasmtime before versi...
vendor_debian·2021·CVSS 6.3
CVE-2021-39219 [MEDIUM] CVE-2021-39219: rust-wasmtime - Wasmtime is an open source runtime for WebAssembly & WASI. Wasmtime before versi...
Wasmtime is an open source runtime for WebAssembly & WASI. Wasmtime before version 0.30.0 is affected by a type confusion vulnerability. As a Rust library the `wasmtime` crate clearly marks which functions are safe and which are `unsafe`, guaranteeing that if consumers never use `unsafe` then it should not be possible to have memory unsafety issues in their embeddings of Wasmtime. An issue was discovered in the safe API of `Linker::func_*` APIs. These APIs were previously not sound when one `Engine` was used to create the `Linker` and then a different `Engine` was used to create a `Store` and then the `Linker` was 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, resulti
No detection rules found.
No public exploits indexed.
No writeups or analysis indexed.
https://crates.io/crates/wasmtimehttps://github.com/bytecodealliance/wasmtime/commit/b39f087414f27ae40c44449ed5d1154e03449bffhttps://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-q879-9g95-56mxhttps://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/WAVBRYDDUIY2ZR3K3FO4BVYJKIMJ5TP7/https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/Z2Z33FTXFQ6EOINVEQIP4DFBG53G5XIY/https://crates.io/crates/wasmtimehttps://github.com/bytecodealliance/wasmtime/commit/b39f087414f27ae40c44449ed5d1154e03449bffhttps://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-q879-9g95-56mxhttps://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/WAVBRYDDUIY2ZR3K3FO4BVYJKIMJ5TP7/https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/Z2Z33FTXFQ6EOINVEQIP4DFBG53G5XIY/
2021-09-17
Published