GHSA-v4cp-h94r-m7xf
Use after free passing `externref`s to Wasm in Wasmtime
At a glance
- Published
- Updated
- CVE
- CVE-2021-39216, CVE-2021-39218, CVE-2021-39219
- Aliases
- GHSA-4873-36h9-wv49, GHSA-q879-9g95-56mx, PYSEC-2021-320, PYSEC-2021-321, PYSEC-2021-322, RUSTSEC-2021-0110
- CVSS_V3
- CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H
- CVSS_V4
- CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N
Description
### 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 `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. ### Patches The bug has been fixed, and users should upgrade to Wasmtime 0.30.0. Additionally, we have updated [our primary `externref` fuzz target](https://github.com/bytecodealliance/wasmtime/blob/37c094faf53f1b356aab3c79d451395e4f7edb34/fuzz/fuzz_targets/table_ops.rs) such that it better exercises these code paths and we can have greater confidence in their correctness going forward. ### Workarounds 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`](https://docs.rs/wasmtime/0.29.0/wasmtime/struct.Config.html#method.wasm_reference_types). ### References * [The reference types Wasm proposal, which introduces `externref`](https://github.com/WebAssembly/reference-types/) ### For more information If you have any questions or comments about this advisory: * Reach out to us on [the Bytecode Alliance Zulip chat](https://bytecodealliance.zulipchat.com/#narrow/stream/217126-wasmtime) * Open an issue in [the `bytecodealliance/wasmtime` repository](https://github.com/bytecodealliance/wasmtime/)
Affected packages
| Package | Versions |
|---|---|
| crates.io · wasmtime | introduced 0, fixed 0.30.0 |
| PyPI · wasmtime | introduced 0, fixed 0.30.0 |
References
- https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-v4cp-h94r-m7xf WEB
- https://nvd.nist.gov/vuln/detail/CVE-2021-39216 ADVISORY
- https://github.com/bytecodealliance/wasmtime/commit/101998733b74624cbd348a2366d05760b40181f3 WEB
- https://crates.io/crates/wasmtime WEB
- https://github.com/bytecodealliance/wasmtime PACKAGE
- https://github.com/bytecodealliance/wasmtime-py/compare/0.29.0...0.30.0 WEB
- https://github.com/pypa/advisory-database/tree/main/vulns/wasmtime/PYSEC-2021-320.yaml WEB
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/WAVBRYDDUIY2ZR3K3FO4BVYJKIMJ5TP7 WEB
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/Z2Z33FTXFQ6EOINVEQIP4DFBG53G5XIY WEB
- https://rustsec.org/advisories/RUSTSEC-2021-0110.html WEB
Sources
| Source | Licence |
|---|---|
| OSV.dev | CC-BY 4.0 — GitHub Advisory Database |