CVE-2021-39218
published 2021-09-17CVE-2021-39218: 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…
PriorityP431medium6.3CVSS 3.1
AVLACHPRLUINSUCNIHAH
EPSS
0.29%
20.7th percentile
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 safepoint. This would result in Wasmtime treating arbitrary stack slots as `externref`s that needed to be rooted for GC. At the *next* GC, it would be determined that nothing was referencing these bogus `externref`s (because nothing could ever reference them, because they are not really `externref`s) and then Wasmtime would deallocate them and run `::drop` on them. This results in a free of memory that is not necessarily on the heap (and shouldn't be freed at this moment even if it was), as well as potential out-of-bounds reads and writes. Even though support for `externref`s (via the reference types proposal) is enabled by default, unless you are creating non-null `externref`s in your host code or explicitly triggering GCs, you cannot be affected by this bug. We have reason to believe that the effective impact of this bug is relatively small because usage of `externref` is currently quite rare. This bug has been patched and users should upgrade to Wasmtime version 0.30.0. If you cannot upgrade Wasmtime at this time, you can avoid this bug by disabling the reference types proposal 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.26.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
Out-of-bounds read/write and invalid free with `externref`s and GC safepoints in Wasmtime
ghsa·2021-09-20
CVE-2021-39218 [MEDIUM] CWE-125 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
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-39218: rust-wasmtime - Wasmtime is an open source runtime for WebAssembly & WASI. In Wasmtime from vers...
vendor_debian·2021·CVSS 6.3
CVE-2021-39218 [MEDIUM] CVE-2021-39218: 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.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
No detection rules found.
No public exploits indexed.
No writeups or analysis indexed.
https://crates.io/crates/wasmtimehttps://github.com/bytecodealliance/wasmtime/commit/398a73f0dd862dbe703212ebae8e34036a18c11chttps://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-4873-36h9-wv49https://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/398a73f0dd862dbe703212ebae8e34036a18c11chttps://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-4873-36h9-wv49https://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