Skip to content

GHSA-ch89-5g45-qwc7 CVE-2023-30624 RUSTSEC-2023-0092

Undefined Behavior in Rust runtime functions

High crates.io
Severity
3.9 / 10
High · CVSS 3.1
Exploit chance (EPSS)
0.45%
Chance of exploitation in the next 30 days. Higher than 39.08% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-758 Reliance on Undefined, Unspecified, or Implementation-Defined Behavior
Fix
6.0.2
Upgrade wasmtime to this version or later

Description

Impact

Wasmtime's implementation of managing per-instance state, such as tables and memories, contains LLVM-level undefined behavior. This undefined behavior was found to cause runtime-level issues when compiled with LLVM 16 which causes some writes, which are critical for correctness, to be optimized away. Vulnerable versions of Wasmtime compiled with Rust 1.70, which is currently in beta, or later are known to have incorrectly compiled functions. Versions of Wasmtime compiled with the current Rust stable release, 1.69, and prior are not known at this time to have any issues, but can theoretically exhibit potential issues.

The underlying problem is that Wasmtime's runtime state for an instance involves a Rust-defined structure called Instance which has a trailing VMContext structure after it. This VMContext structure has a runtime-defined layout that is unique per-module. This representation cannot be expressed with safe code in Rust so unsafe code is required to maintain this state. The code doing this, however, has methods which take &self as an argument but modify data in the VMContext part of the allocation. This means that pointers derived from &self are mutated. This is typically not allowed, except in the presence of UnsafeCell, in Rust. When compiled to LLVM these functions have noalias readonly parameters which means it's UB to write through the pointers.

Wasmtime's internal representation and management of VMContext has been updated to use &mut self methods where appropriate. Additionally verification tools for unsafe code in Rust, such as cargo miri, are planned to be executed on the main branch soon to fix any Rust-level issues that may be exploited in future compiler versions.

Precomplied binaries available for Wasmtime from GitHub releases have been compiled with at most LLVM 15 so are not known to be vulnerable. As mentioned above, however, it's still recommended to update.

Patches

Wasmtime version 6.0.2, 7.0.1, and 8.0.1 have been issued which contain the patch necessary to work correctly on LLVM 16 and have no known UB on LLVM 15 and earlier.

Workarounds

If Wasmtime is compiled with Rust 1.69 and prior, which use LLVM 15, then there are no known issues. There is a theoretical possibility for UB to exploited, however, so it's recommended that users upgrade to a patched version of Wasmtime. Users using beta Rust (1.70 at this time) or nightly Rust (1.71 at this time) must update to a patched version to work correctly.

References

For more information

If you have any questions or comments about this advisory:

Affected versions

crates.io

PackageVulnerableFixed in
wasmtime
< 6.0.2
6.0.2
wasmtime
>= 7.0.0, < 7.0.1
7.0.1
wasmtime
>= 8.0.0, < 8.0.1
8.0.1
wasmtime
>= 0.0.0-0, < 6.0.2
>= 7.0.0, < 7.0.1
>= 8.0.0, < 8.0.1
6.0.2
7.0.1
8.0.1

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

wasmtime crates.io → 6.0.2

cargo
cargo update -p wasmtime --precise 6.0.2

Severity breakdown

CVSS 3.1 3.9

CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:L/I:L/A:L

Attack vector
Network
Attack complexity
High
Privileges required
High
User interaction
Required
Scope
Unchanged
Confidentiality
Low
Integrity
Low
Availability
Low

Weakness

CWE-758: Reliance on Undefined, Unspecified, or Implementation-Defined Behavior

The product uses an API function, data structure, or other entity in a way that relies on properties that are not always guaranteed to hold for that entity.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
RUSTSEC-2026-0424
Unchecked memory usage in transferring borrowed resources between components
Not rated yet Also affects wasmtime
RUSTSEC-2026-0423
Cross-engine type confusion with host-created struct-types-with-supertypes
Not rated yet Also affects wasmtime
RUSTSEC-2026-0422
Typed functions with `i31` or `nullref` arguments may panic due to insufficient type-check
Low Also affects wasmtime
RUSTSEC-2026-0379
Wasmtime: Cranelift backend on aarch64 can jump to incorrect target on large Wasm `br_table` instruction
Critical Also affects wasmtime
GHSA-9pvw-hwfg-92h5
Wasmtime: Panic lowering a host-created component model stream into a guest that expects a different payload type
Medium Also affects wasmtime
GHSA-897f-g5gm-fmxm
Wasmtime: Bit-packing in Cranelift compiler causes silent overflow and miscompilation
Critical Also affects wasmtime
RUSTSEC-2026-0364
Exception tags can cause host data structures to be unaligned
Not rated yet Also affects wasmtime
RUSTSEC-2026-0363
Component-model handle tables are capped only per instance and charged to no limit
Medium Also affects wasmtime
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor