CVE-2021-39216: Use after free passing `externref`s to Wasm in Wasmtime

Published Sep 17, 2021
·
Updated

Impact

There was a use-after-free bug when passing externrefs from the host to guest Wasm content.

To trigger the bug, you have to explicitly pass multiple externrefs from the host to a Wasm instance at the same time, either 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 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.

Patches

The bug has been fixed, and users should upgrade to Wasmtime 0.30.0.

Additionally, we have updated our primary externref fuzz target 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::wasmreferencetypes.

References

The reference types Wasm proposal, which introduces externref

For more information

If you have any questions or comments about this advisory:

Reach out to us on the Bytecode Alliance Zulip chat Open an issue in the bytecodealliance/wasmtime repository

Other sources

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 externrefs from the host to guest Wasm content. To trigger the bug, you have to explicitly pass multiple externrefs from the host to a Wasm instance at the same time, either 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 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::wasmreferencetypes.

Affected Software

5 affected componentsFixes available
pip/wasmtime>=0<0.30.0
0.30.0
rust/wasmtime<0.30.0
0.30.0
bytecodealliance Wasmtime>=0.19.0<0.30.0
Fedoraproject Fedora=34
Fedoraproject Fedora=35

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade pip/wasmtime to a version that resolves this vulnerability.

    Fixed in 0.30.0
  2. Upgrade

    Upgrade rust/wasmtime to a version that resolves this vulnerability.

    Fixed in 0.30.0
  3. Upgrade

    Upgrade wasmtime to a version that resolves this vulnerability.

    Fixed in 0.30.0
  4. Configuration

    If you cannot upgrade, disable reference types support by passing `false` to `wasmtime::Config::wasm_reference_types` so `externref` handling is not used.

    Wasmtime wasmtime::Config::wasm_reference_types = false

Event History

Sep 17, 2021
CVE Published
via MITRE·08:05 PM
Data Sourced
via MITRE·08:05 PM
DescriptionSeverityWeakness
Data Sourced
via NVD·08:15 PM
DescriptionSeverityWeaknessAffected Software
Sep 20, 2021
Advisory Published
via GitHub·07:54 PM
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is CVE-2021-39216?

CVE-2021-39216 is a use-after-free vulnerability in Wasmtime.

2

What is the severity of CVE-2021-39216?

CVE-2021-39216 has a severity rating of 6.3 (Medium).

3

How does CVE-2021-39216 affect Wasmtime?

CVE-2021-39216 affects Wasmtime versions 0.19.0 to 0.30.0.

4

How can the use-after-free bug in Wasmtime be triggered?

To trigger the use-after-free bug in Wasmtime, you have to explicitly pass multiple externrefs from the host to guest Wasm content.

5

Are there any references for CVE-2021-39216?

Yes, you can find references for CVE-2021-39216 at the following URLs: [https://crates.io/crates/wasmtime](https://crates.io/crates/wasmtime), [https://github.com/bytecodealliance/wasmtime/commit/101998733b74624cbd348a2366d05760b40181f3](https://github.com/bytecodealliance/wasmtime/commit/101998733b74624cbd348a2366d05760b40181f3), [https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-v4cp-h94r-m7xf](https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-v4cp-h94r-m7xf)

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203