CVE-2022-39392

Workarounds

One way to mitigate this issue is to disable usage of the pooling allocator. Note that the pooling allocator is not enabled by default.

This bug can also only be worked around by increasing the memory_pages allotment when configuring the pooling allocator to a value greater than zero. If an embedding wishes to still prevent memory from actually being used then the Store::limiter method can be used to dynamically disallow growth of memory beyond 0 bytes large. Note that the default memory_pages value is greater than zero.

This bug is not applicable with the default settings of the wasmtime crate.

References

• Config::allocation_strategy - configuration required to enable the pooling allocator.
• InstanceLimits::memory_pages - configuration field that, when zero, exhibits this bug.
• Store::limiter - means of limiting memory without using memory_pages
• Mailing list announcement
• Patch for the release-2.0.0 branch

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

There is a bug in Wasmtime's implementation of its pooling instance allocator when the allocator is configured to give WebAssembly instances a maximum of zero pages of memory. In this configuration the virtual memory mapping for WebAssembly memories did not meet the compiler-required configuration requirements for safely executing WebAssembly modules. Wasmtime's default settings require virtual memory page faults to indicate that wasm reads/writes are out-of-bounds, but the pooling allocator's configuration would not create an appropriate virtual memory mapping for this meaning out of bounds reads/writes can successfully read/write memory unrelated to the wasm sandbox within range of the base address of the memory mapping created by the pooling allocator.

This bug can only be triggered by setting InstanceLimits::memory_pages to zero. This is expected to be a very rare configuration since this means that wasm modules cannot allocate any pages of linear memory. All wasm modules produced by all current toolchains are highly likely to use linear memory, so it's expected to be unlikely that this configuration is set to zero by any production embedding of Wasmtime, hence the low severity of this bug despite the critical consequences.

A read operation accesses a memory location beyond the intended buffer boundary. Typical impact: sensitive data disclosure or crash.

CVE-2022-39392 has a CVSS score of 5.9 (Medium). The vector is network-reachable, high privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (2.0.2, 1.0.2); upgrading removes the vulnerable code path.

Kodem intelligence

This bug has been patched and users should upgrade to Wasmtime 2.0.2.

1. What is CVE-2022-39392? CVE-2022-39392 is a medium-severity out-of-bounds read vulnerability in wasmtime (rust), affecting versions >= 2.0.0, < 2.0.2. It is fixed in 2.0.2, 1.0.2. A read operation accesses a memory location beyond the intended buffer boundary.
2. How severe is CVE-2022-39392? CVE-2022-39392 has a CVSS score of 5.9 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of wasmtime are affected by CVE-2022-39392? wasmtime (rust) versions >= 2.0.0, < 2.0.2 is affected.
4. Is there a fix for CVE-2022-39392? Yes. CVE-2022-39392 is fixed in 2.0.2, 1.0.2. Upgrade to this version or later.
5. Is CVE-2022-39392 exploitable, and should I be worried? Whether CVE-2022-39392 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2022-39392 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2022-39392?
   • Upgrade wasmtime to 2.0.2 or later
   • Upgrade wasmtime to 1.0.2 or later