Read the docs
TI-2021-16604 Aliases CVE-2021-39219GHSA-q879-9g95-56mx

Wrong type for `Linker`-define functions when used across two `Engine`s

Priority LOW 28CWE-843Published · Updated

Key facts

Attack vector
Local
Privileges required
None
User interaction
Required
Attack complexity
High
Impact type
—
Confidentiality · integrity · availability
None · High · High
Fix status
Fixed

Attack profile from CVSS 3.1 · CNA. Fix status from CNA and GitHub.

Summary

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, resulting in being able to safely call a function with the wrong type. Triggering this bug requires using at least two `Engine` values in an embedding and then additionally using two different values with a `Linker` (one at the creation time of the `Linker` and another when instantiating a module with the `Linker`). It's expected that usage of more-than-one `Engine` in an embedding is relatively rare since an `Engine` is intended to be a globally shared resource, so the expectation is that the impact of this issue is relatively small. The fix implemented is to change this behavior to `panic!()` in Rust instead of silently allowing it. Using different `Engine` instances with a `Linker` is a programmer bug that `wasmtime` catches at runtime. This bug has been patched and users should upgrade to Wasmtime version 0.30.0. If you cannot upgrade Wasmtime and 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 `Engine`s is required then code should be audited to ensure that `Linker` is only used with one `Engine`.

Why it matters now

EPSS 0.00361 30th percentileScored 2026-11-07
Fix Fixed wasmtime (crates.io): 0.30.0wasmtime (PyPI): 0.30.0

SSVC decision points

Not available: CISA has not published SSVC decision points for this record.

Affected products

VendorProductAffected versionsFixed inStatusSource
bytecodealliancewasmtimeup to 0.29.0—No fix listedCNA
—wasmtime (crates.io)before 0.30.00.30.0Patch availableGHSA-q879-9g95-56mx
—wasmtime (PyPI)before 0.30.00.30.0Patch availableGHSA-q879-9g95-56mx
  • wasmtime Vendorbytecodealliance Affected up to 0.29.0 Fixed in — No fix listed CNA
  • wasmtime (crates.io) Vendor— Affected before 0.30.0 Fixed in 0.30.0 Patch available GHSA-q879-9g95-56mx
  • wasmtime (PyPI) Vendor— Affected before 0.30.0 Fixed in 0.30.0 Patch available GHSA-q879-9g95-56mx

CPE configurations NVD · 3

CPEVersionsRoleVendor
cpe:2.3:a:bytecodealliance:wasmtime:*:*:*:*:*:*:*:*before 0.30.0Vulnerablebytecodealliance
cpe:2.3:o:fedoraproject:fedora:34:*:*:*:*:*:*:*34VulnerableFedoraproject
cpe:2.3:o:fedoraproject:fedora:35:*:*:*:*:*:*:*35VulnerableFedoraproject
  • cpe:2.3:a:bytecodealliance:wasmtime:*:*:*:*:*:*:*:* Versions before 0.30.0 Vulnerable ·bytecodealliance
  • cpe:2.3:o:fedoraproject:fedora:34:*:*:*:*:*:*:* Versions 34 Vulnerable ·Fedoraproject
  • cpe:2.3:o:fedoraproject:fedora:35:*:*:*:*:*:*:* Versions 35 Vulnerable ·Fedoraproject

Remediation

  • Fix · GHSA-q879-9g95-56mx wasmtime (crates.io) Fixed in 0.30.0 Advisory →
  • Fix · GHSA-q879-9g95-56mx wasmtime (PyPI) Fixed in 0.30.0 Advisory →

Fixed in the same release

Records fixed by the same vendor advisory or release, as the CNA lists them.

  • Advisory ·

    bytecodealliance wasmtime — FEDORA-2021-1805eacb48

    3 records Highest priority Priority LOW 3 LOW

    Other records, highest priority first

    • TI-2021-16603 Out-of-bounds read/write and invalid free with `externref`s and GC safepoints in WasmtimePriority LOW 28
    • TI-2021-16601 Use after free passing `externref`s to Wasm in WasmtimePriority LOW 28
  • Advisory ·

    bytecodealliance wasmtime — FEDORA-2021-68713440cb

    3 records Highest priority Priority LOW 3 LOW

    Other records, highest priority first

    • TI-2021-16603 Out-of-bounds read/write and invalid free with `externref`s and GC safepoints in WasmtimePriority LOW 28
    • TI-2021-16601 Use after free passing `externref`s to Wasm in WasmtimePriority LOW 28

Vendor assessments

Red Hat

Red Hat's page for this CVE →

Not affected: 1 product
  • Red Hat

Timeline

  1. 2026-10-02 Threatist record created from CVE-2021-39219
  2. 2026-10-03 Alias added: GHSA-q879-9g95-56mx

References

  • TI-2026-21632 Wasmtime is vulnerable to panic when dropping a `[Typed]Func::call_async` future CVSS 4.0MEDIUM 6.9
  • TI-2023-11636 Guest-controlled out-of-bounds read/write on x86_64 in wasmtime CVSS 3.1CRITICAL 10.0
  • TI-2022-18765 Wasmtime vulnerable to data leakage between instances in the pooling allocator CVSS 3.1HIGH 8.6
  • TI-2022-08604 Use after free in Wasmtime CVSS 3.1CRITICAL 9.8
  • TI-2022-18766 wasmtime_trap_code C API function has out of bounds write vulnerability CVSS 3.1CRITICAL 9.8
  • TI-2026-27209 Wasmtime with Winch compiler backend on aarch64 may allow a sandbox-escaping memory access CVSS 4.0CRITICAL 9.0
See all 40 →

Sources