CVE-2021-39216
published 2021-09-17CVE-2021-39216: 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…
PriorityP428medium6.3CVSS 3.1
AVLACHPRLUINSUCNIHAH
EPSS
0.30%
21.3th percentile
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. However the first `externref` is not rooted until we pass control to Wasm, and therefore could be reclaimed by the collector if nothing else was holding a reference to it or otherwise keeping it alive. Then, when control was passed to Wasm after the garbage collection, Wasm could use the first `externref`, which at this point has already been freed. We have reason to believe that the effective impact of this bug is relatively small because usage of `externref` is currently quite rare. The bug has been fixed, and users should upgrade to Wasmtime 0.30.0. If you cannot upgrade Wasmtime yet, you can avoid the bug by disabling reference types support in Wasmtime by passing `false` to `wasmtime::Config::wasm_reference_types`.
Affected
13 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| bytecodealliance | wasmtime | — | — |
| 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.19.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
Use after free passing `externref`s to Wasm in Wasmtime
ghsa·2021-09-20
CVE-2021-39216 [MEDIUM] CWE-416 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
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-39216: rust-wasmtime - Wasmtime is an open source runtime for WebAssembly & WASI. In Wasmtime from vers...
vendor_debian·2021·CVSS 6.3
CVE-2021-39216 [MEDIUM] CVE-2021-39216: rust-wasmtime - Wasmtime is an open source runtime for WebAssembly & WASI. In Wasmtime from vers...
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
No detection rules found.
No public exploits indexed.
No writeups or analysis indexed.
https://crates.io/crates/wasmtimehttps://github.com/bytecodealliance/wasmtime/commit/101998733b74624cbd348a2366d05760b40181f3https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-v4cp-h94r-m7xfhttps://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/101998733b74624cbd348a2366d05760b40181f3https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-v4cp-h94r-m7xfhttps://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