PT-2021-22468 · Wasmtime · Wasmtime
Fitzgen
·
Published
2021-09-17
·
Updated
2021-12-21
·
CVE-2021-39216
CVSS v3.1
6.3
Medium
| Vector | AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H |
Name of the Vulnerable Software and Affected Versions
Wasmtime versions 0.19.0 through 0.29.0
Description
The issue is related to a use-after-free bug when passing
externrefs from the host to guest Wasm content. To trigger the bug, multiple externrefs must be passed from the host to a Wasm instance at the same time. The bug can be triggered by passing multiple externrefs as arguments from host code to a Wasm function or returning multiple externrefs to Wasm from a multi-value return function defined in the host. If Wasmtime's VMExternRefActivationsTable becomes 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 control is passed 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. Additionally, there is an invalid free and out-of-bounds read and write bug when running Wasm that uses externrefs in Wasmtime. The bug can be triggered when Wasmtime is running Wasm that uses externrefs, the host creates non-null externrefs, Wasmtime performs a garbage collection, 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. The estimated impact of these bugs is relatively small because usage of externref is currently quite rare.Recommendations
For Wasmtime versions 0.19.0 through 0.29.0, upgrade to Wasmtime 0.30.0 to fix the bug.
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.
If you 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 Engines is required, then code should be audited to ensure that Linker is only used with one Engine.Fix
Memory Corruption
Use After Free
Out of bounds Read
Type Confusion
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Wasmtime