| Affected_by_vulnerabilities |
| 0 |
| url |
VCID-25cp-12ta-pkf5 |
| vulnerability_id |
VCID-25cp-12ta-pkf5 |
| summary |
Wasmtime is a standalone runtime for WebAssembly. Prior to version 2.0.2, there is a bug in Wasmtime's C API implementation where the definition of the `wasmtime_trap_code` does not match its declared signature in the `wasmtime/trap.h` header file. This discrepancy causes the function implementation to perform a 4-byte write into a 1-byte buffer provided by the caller. This can lead to three zero bytes being written beyond the 1-byte location provided by the caller. This bug has been patched and users should upgrade to Wasmtime 2.0.2. This bug can be worked around by providing a 4-byte buffer casted to a 1-byte buffer when calling `wasmtime_trap_code`. Users of the `wasmtime` crate are not affected by this issue, only users of the C API function `wasmtime_trap_code` are affected. |
| references |
|
| fixed_packages |
|
| aliases |
CVE-2022-39394, GHSA-h84q-m8rr-3v9q
|
| risk_score |
1.7 |
| exploitability |
0.5 |
| weighted_severity |
3.4 |
| resource_url |
http://public2.vulnerablecode.io/vulnerabilities/VCID-25cp-12ta-pkf5 |
|
| 1 |
|
| 2 |
| url |
VCID-dz8d-qafr-rfh9 |
| vulnerability_id |
VCID-dz8d-qafr-rfh9 |
| summary |
Wasmtime is a standalone runtime for WebAssembly. Prior to versions 6.0.2, 7.0.1, and 8.0.1, 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.
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. 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 undefined behavior 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 |
|
| fixed_packages |
|
| aliases |
CVE-2023-30624, GHSA-ch89-5g45-qwc7
|
| risk_score |
null |
| exploitability |
null |
| weighted_severity |
null |
| resource_url |
http://public2.vulnerablecode.io/vulnerabilities/VCID-dz8d-qafr-rfh9 |
|
| 3 |
| url |
VCID-jna6-cwap-vuhv |
| vulnerability_id |
VCID-jna6-cwap-vuhv |
| summary |
Wasmtime is a standalone runtime for WebAssembly. Prior to versions 2.0.2 and 1.0.2, there is a bug in Wasmtime's implementation of its pooling instance allocator where when a linear memory is reused for another instance the initial heap snapshot of the prior instance can be visible, erroneously to the next instance. This bug has been patched and users should upgrade to Wasmtime 2.0.2 and 1.0.2. Other mitigations include disabling the pooling allocator and disabling the `memory-init-cow`. |
| references |
|
| fixed_packages |
|
| aliases |
CVE-2022-39393, GHSA-wh6w-3828-g9qf
|
| risk_score |
4.0 |
| exploitability |
0.5 |
| weighted_severity |
8.0 |
| resource_url |
http://public2.vulnerablecode.io/vulnerabilities/VCID-jna6-cwap-vuhv |
|
| 4 |
| url |
VCID-pbn9-qd2w-37fk |
| vulnerability_id |
VCID-pbn9-qd2w-37fk |
| summary |
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 `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` 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::wasm_reference_types`. |
| references |
| 0 |
|
| 1 |
|
| 2 |
|
| 3 |
| reference_url |
https://crates.io/crates/wasmtime |
| reference_id |
|
| reference_type |
|
| scores |
| 0 |
| value |
6.3 |
| scoring_system |
cvssv3.1 |
| scoring_elements |
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H |
|
| 1 |
| value |
6.3 |
| scoring_system |
cvssv3.1 |
| scoring_elements |
CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:H |
|
| 2 |
| value |
5.8 |
| scoring_system |
cvssv4 |
| scoring_elements |
CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N |
|
| 3 |
| value |
5.8 |
| scoring_system |
cvssv4 |
| scoring_elements |
CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:P/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N |
|
| 4 |
| value |
6.1 |
| scoring_system |
cvssv4 |
| scoring_elements |
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 |
|
| 5 |
| value |
MODERATE |
| scoring_system |
generic_textual |
| scoring_elements |
|
|
|
| url |
https://crates.io/crates/wasmtime |
|
| 4 |
| reference_url |
https://github.com/bytecodealliance/wasmtime |
| reference_id |
|
| reference_type |
|
| scores |
| 0 |
| value |
6.3 |
| scoring_system |
cvssv3.1 |
| scoring_elements |
CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:H |
|
| 1 |
| value |
6.3 |
| scoring_system |
cvssv3.1 |
| scoring_elements |
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H |
|
| 2 |
| value |
5.8 |
| scoring_system |
cvssv4 |
| scoring_elements |
CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N |
|
| 3 |
| value |
5.8 |
| scoring_system |
cvssv4 |
| scoring_elements |
CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:P/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N |
|
| 4 |
| value |
6.1 |
| scoring_system |
cvssv4 |
| scoring_elements |
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 |
|
| 5 |
| value |
MODERATE |
| scoring_system |
generic_textual |
| scoring_elements |
|
|
|
| url |
https://github.com/bytecodealliance/wasmtime |
|
| 5 |
|
| 6 |
|
| 7 |
|
| 8 |
| reference_url |
https://github.com/bytecodealliance/wasmtime-py/compare/0.29.0...0.30.0 |
| reference_id |
|
| reference_type |
|
| scores |
| 0 |
| value |
6.3 |
| scoring_system |
cvssv3.1 |
| scoring_elements |
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H |
|
| 1 |
| value |
6.3 |
| scoring_system |
cvssv3.1 |
| scoring_elements |
CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:H |
|
| 2 |
| value |
5.8 |
| scoring_system |
cvssv4 |
| scoring_elements |
CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:P/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N |
|
| 3 |
| value |
5.8 |
| scoring_system |
cvssv4 |
| scoring_elements |
CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N |
|
| 4 |
| value |
6.1 |
| scoring_system |
cvssv4 |
| scoring_elements |
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 |
|
| 5 |
| value |
MODERATE |
| scoring_system |
generic_textual |
| scoring_elements |
|
|
|
| url |
https://github.com/bytecodealliance/wasmtime-py/compare/0.29.0...0.30.0 |
|
| 9 |
|
| 10 |
|
| 11 |
|
| 12 |
|
| 13 |
|
| 14 |
|
| 15 |
|
| 16 |
|
| 17 |
|
| 18 |
|
| 19 |
|
| 20 |
|
| 21 |
|
| 22 |
| reference_url |
https://rustsec.org/advisories/RUSTSEC-2021-0110.html |
| reference_id |
|
| reference_type |
|
| scores |
| 0 |
| value |
6.3 |
| scoring_system |
cvssv3.1 |
| scoring_elements |
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H |
|
| 1 |
| value |
6.3 |
| scoring_system |
cvssv3.1 |
| scoring_elements |
CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:H |
|
| 2 |
| value |
5.8 |
| scoring_system |
cvssv4 |
| scoring_elements |
CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N |
|
| 3 |
| value |
5.8 |
| scoring_system |
cvssv4 |
| scoring_elements |
CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:P/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N |
|
| 4 |
| value |
6.1 |
| scoring_system |
cvssv4 |
| scoring_elements |
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 |
|
| 5 |
| value |
MODERATE |
| scoring_system |
generic_textual |
| scoring_elements |
|
|
|
| url |
https://rustsec.org/advisories/RUSTSEC-2021-0110.html |
|
| 23 |
|
| 24 |
|
| 25 |
|
|
| fixed_packages |
|
| aliases |
CVE-2021-39216, CVE-2021-39218, CVE-2021-39219, GHSA-4873-36h9-wv49, GHSA-q879-9g95-56mx, GHSA-v4cp-h94r-m7xf, PYSEC-2021-320, PYSEC-2021-321, PYSEC-2021-322, RUSTSEC-2021-0110
|
| risk_score |
null |
| exploitability |
0.5 |
| weighted_severity |
0.0 |
| resource_url |
http://public2.vulnerablecode.io/vulnerabilities/VCID-pbn9-qd2w-37fk |
|
| 5 |
| url |
VCID-qqfr-qtfq-53bx |
| vulnerability_id |
VCID-qqfr-qtfq-53bx |
| summary |
Wasmtime is a standalone runtime for WebAssembly. There is a bug in Wasmtime's code generator, Cranelift, for AArch64 targets where constant divisors can result in incorrect division results at runtime. This affects Wasmtime prior to version 0.38.2 and Cranelift prior to 0.85.2. This issue only affects the AArch64 platform. Other platforms are not affected. The translation rules for constants did not take into account whether sign or zero-extension should happen which resulted in an incorrect value being placed into a register when a division was encountered. The impact of this bug is that programs executing within the WebAssembly sandbox would not behave according to the WebAssembly specification. This means that it is hypothetically possible for execution within the sandbox to go awry and WebAssembly programs could produce unexpected results. This should not impact hosts executing WebAssembly but does affect the correctness of guest programs. This bug has been patched in Wasmtime version 0.38.2 and cranelift-codegen 0.85.2. There are no known workarounds. |
| references |
|
| fixed_packages |
|
| aliases |
CVE-2022-31169, GHSA-7f6x-jwh5-m9r4
|
| risk_score |
null |
| exploitability |
null |
| weighted_severity |
null |
| resource_url |
http://public2.vulnerablecode.io/vulnerabilities/VCID-qqfr-qtfq-53bx |
|
| 6 |
| url |
VCID-wcxz-tsc3-pkhq |
| vulnerability_id |
VCID-wcxz-tsc3-pkhq |
| summary |
Wasmtime is a standalone runtime for WebAssembly. In affected versions wasmtime's implementation of the SIMD proposal for WebAssembly on x86_64 contained two distinct bugs in the instruction lowerings implemented in Cranelift. The aarch64 implementation of the simd proposal is not affected. The bugs were presented in the `i8x16.swizzle` and `select` WebAssembly instructions. The `select` instruction is only affected when the inputs are of `v128` type. The correspondingly affected Cranelift instructions were `swizzle` and `select`. The `swizzle` instruction lowering in Cranelift erroneously overwrote the mask input register which could corrupt a constant value, for example. This means that future uses of the same constant may see a different value than the constant itself. The `select` instruction lowering in Cranelift wasn't correctly implemented for vector types that are 128-bits wide. When the condition was 0 the wrong instruction was used to move the correct input to the output of the instruction meaning that only the low 32 bits were moved and the upper 96 bits of the result were left as whatever the register previously contained (instead of the input being moved from). The `select` instruction worked correctly if the condition was nonzero, however. This bug in Wasmtime's implementation of these instructions on x86_64 represents an incorrect implementation of the specified semantics of these instructions according to the WebAssembly specification. The impact of this is benign for hosts running WebAssembly but represents possible vulnerabilities within the execution of a guest program. For example a WebAssembly program could take unintended branches or materialize incorrect values internally which runs the risk of exposing the program itself to other related vulnerabilities which can occur from miscompilations. We have released Wasmtime 0.38.1 and cranelift-codegen (and other associated cranelift crates) 0.85.1 which contain the corrected implementations of these two instructions in Cranelift. If upgrading is not an option for you at this time, you can avoid the vulnerability by disabling the Wasm simd proposal. Additionally the bug is only present on x86_64 hosts. Other aarch64 hosts are not affected. Note that s390x hosts don't yet implement the simd proposal and are not affected. |
| references |
| 0 |
|
| 1 |
|
| 2 |
|
| 3 |
|
| 4 |
|
| 5 |
|
| 6 |
|
| 7 |
|
| 8 |
|
| 9 |
| reference_url |
https://github.com/webassembly/simd |
| reference_id |
simd |
| reference_type |
|
| scores |
| 0 |
| value |
4.8 |
| scoring_system |
cvssv3.1 |
| scoring_elements |
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:L |
|
| 1 |
| value |
MODERATE |
| scoring_system |
generic_textual |
| scoring_elements |
|
|
| 2 |
| value |
Track |
| scoring_system |
ssvc |
| scoring_elements |
SSVCv2/E:N/A:N/T:P/P:M/B:A/M:M/D:T/2025-04-23T14:04:13Z/ |
|
|
| url |
https://github.com/webassembly/simd |
|
| 10 |
|
| 11 |
|
|
| fixed_packages |
|
| aliases |
CVE-2022-31104, GHSA-jqwc-c49r-4w2x
|
| risk_score |
null |
| exploitability |
null |
| weighted_severity |
null |
| resource_url |
http://public2.vulnerablecode.io/vulnerabilities/VCID-wcxz-tsc3-pkhq |
|
| 7 |
| url |
VCID-wpss-jybg-7kd5 |
| vulnerability_id |
VCID-wpss-jybg-7kd5 |
| summary |
Cranelift is an open-source code generator maintained by Bytecode Alliance. It translates a target-independent intermediate representation into executable machine code. There is a bug in 0.73 of the Cranelift x64 backend that can create a scenario that could result in a potential sandbox escape in a Wasm program. This bug was introduced in the new backend on 2020-09-08 and first included in a release on 2020-09-30, but the new backend was not the default prior to 0.73. The recently-released version 0.73 with default settings, and prior versions with an explicit build flag to select the new backend, are vulnerable. The bug in question performs a sign-extend instead of a zero-extend on a value loaded from the stack, under a specific set of circumstances. If those circumstances occur, the bug could allow access to memory addresses upto 2GiB before the start of the Wasm program heap. If the heap bound is larger than 2GiB, then it would be possible to read memory from a computable range dependent on the size of the heaps bound. The impact of this bug is highly dependent on heap implementation, specifically: * if the heap has bounds checks, and * does not rely exclusively on guard pages, and * the heap bound is 2GiB or smaller * then this bug cannot be used to reach memory from another Wasm program heap. The impact of the vulnerability is mitigated if there is no memory mapped in the range accessible using this bug, for example, if there is a 2 GiB guard region before the Wasm program heap. The bug in question performs a sign-extend instead of a zero-extend on a value loaded from the stack, when the register allocator reloads a spilled integer value narrower than 64 bits. This interacts poorly with another optimization: the instruction selector elides a 32-to-64-bit zero-extend operator when we know that an instruction producing a 32-bit value actually zeros the upper 32 bits of its destination register. Hence, we rely on these zeroed bits, but the type of the value is still i32, and the spill/reload reconstitutes those bits as the sign extension of the i32’s MSB. The issue would thus occur when: * An i32 value in a Wasm program is greater than or equal to 0x8000_0000; * The value is spilled and reloaded by the register allocator due to high register pressure in the program between the value’s definition and its use; * The value is produced by an instruction that we know to be “special” in that it zeroes the upper 32 bits of its destination: add, sub, mul, and, or; * The value is then zero-extended to 64 bits in the Wasm program; * The resulting 64-bit value is used. Under these circumstances there is a potential sandbox escape when the i32 value is a pointer. The usual code emitted for heap accesses zero-extends the Wasm heap address, adds it to a 64-bit heap base, and accesses the resulting address. If the zero-extend becomes a sign-extend, the program could reach backward and access memory up to 2GiB before the start of its heap. In addition to assessing the nature of the code generation bug in Cranelift, we have also determined that under specific circumstances, both Lucet and Wasmtime using this version of Cranelift may be exploitable. See referenced GitHub Advisory for more details. |
| references |
|
| fixed_packages |
|
| aliases |
CVE-2021-32629, GHSA-hpqh-2wqx-7qp5, PYSEC-2021-87, RUSTSEC-2021-0067
|
| risk_score |
null |
| exploitability |
0.5 |
| weighted_severity |
0.0 |
| resource_url |
http://public2.vulnerablecode.io/vulnerabilities/VCID-wpss-jybg-7kd5 |
|
|