CVE-2022-39392: Wasmtime vulnerable to out of bounds read/write with zero-memory-pages configuration

Published Nov 10, 2022
·
Updated

Impact

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::memorypages 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.

Patches

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

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 memorypages 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 memorypages value is greater than zero.

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

References

Config::allocationstrategy - configuration required to enable the pooling allocator. InstanceLimits::memorypages - configuration field that, when zero, exhibits this bug. Store::limiter - means of limiting memory without using memorypages 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

Other sources

Wasmtime is a standalone runtime for WebAssembly. Prior to version 2.0.2, 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 is not applicable with the default settings of the wasmtime crate. This bug can only be triggered by setting InstanceLimits::memorypages 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. This bug has been patched and users should upgrade to Wasmtime 2.0.2. This bug can be worked around by increasing the memorypages 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 memorypages value is greater than zero.

Affected Software

4 affected componentsFixes available
bytecodealliance Wasmtime Rust<1.0.2
bytecodealliance Wasmtime Rust>=2.0.0<2.0.2
rust/wasmtime<1.0.2
1.0.2
rust/wasmtime>=2.0.0<2.0.2
2.0.2

Event History

Nov 10, 2022
CVE Published
via MITRE·12:00 AM
Data Sourced
via MITRE·12:00 AM
DescriptionSeverityWeakness
Advisory Published
via GitHub·09:09 PM

Frequently Asked Questions

1

What is CVE-2022-39392?

CVE-2022-39392 is a vulnerability in Wasmtime, a standalone runtime for WebAssembly, prior to version 2.0.2.

2

How severe is CVE-2022-39392?

CVE-2022-39392 has a severity value of 7.4, which is considered high.

3

What is the affected software?

The affected software is Wasmtime version 1.0.2 and versions between 2.0.0 and 2.0.2.

4

What is the vulnerability description of CVE-2022-39392?

CVE-2022-39392 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.

5

How can I fix CVE-2022-39392?

To fix CVE-2022-39392, update Wasmtime to version 2.0.2 or later.

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