GitHub Security Advisory: GHSA-852m-cvvp-9p4w
Package: wasmtime (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-770: Allocation of Resources Without Limits or Throttling, CWE-774: Allocation of File Descriptors or Handles Without Limits or Throttling, CWE-789: Memory Allocation with Excessive Size Value
Vulnerable versions: >= 25.0.0, < 36.0.6
Patched in: 36.0.6

Summary: Wasmtime WASI implementations are vulnerable to guest-controlled resource exhaustion

Details:
### Impact

Wasmtime's implementation of WASI host interfaces are susceptible to guest-controlled resource exhaustion on the host. Wasmtime did not appropriately place limits on resource allocations requested by the guests. This serves as a Denial of Service vector where a guest can induce a range of crashing behaviors on the host such as:

* Allocating arbitrarily large amounts of host memory.
* Causing an allocation failure on the host, which in Rust defaults to aborting the process.
* Causing a panic on the host due to over-large allocations being performed.
* Cause degredation in performance of the host by holding excessive host memory alive.

Wasmtime's [security bug policy](https://docs.wasmtime.dev/security-what-is-considered-a-security-vulnerability.html) considers all of these behaviors a security vulnerability. Wasmtime's implementation of WASI has a number of different ways that resource exhaustion could happen, and fixing any one of them is insufficient from solving this vulnerability. A number of individual issues are grouped within this advisory and as a whole represent the known ways that guests can exhaust resources on the host.

An example of guest-controlled resource exhaustion within Wasmtime's implementation of WASI is guests could repeatedly allocate handles to themselves without limit. Some APIs also caused the host to perform a guest-controlled-sized allocation of a buffer on the host for I/O operations. Other APIs could force the host to buffer arbitrary amounts of data for the guest. Finally the guest could hand arbitrarily large allocations from itself to the host which could cause the host to perform an arbitrarily sized copy of memory which in some situations could result in quadratically sized allocations.

Wasmtime's implementations of WASIp1 and WASIp2 are affected by this vulnerability. Any host API modeled with the Component Model (or WIT) which operates on a `string` or `list<T>` type is also affected. Not all WIT and WASI APIs are affected by this issue, but that's more of an exception so it's recommended for all embedders to consider themselves affected.

To address this issue a number of mitigations are being applied to limit the behavior of a guest in WASI. All of these mitigations manifest in the form of a limit of some kind applied to various situations, and as such all of these mitigations are backwards-incompatible as they run the risk of breaking preexisting programs. To address this all backports to previous stable releases have these limits tuned to overly-large values. This ensures that preexisting guests do not break while still providing embedders the knobs to prevent this DoS vector as well. The limits added to Wasmtime are:

* `-Smax-resources=N` or `ResourceTable::set_max_capacity` - the maximum number of resources that a guest is allowed to allocate for itself.
* `-Shostcall-fuel=N` or `Store::set_hostcall_fuel` - the maximum amount of data that the guest may copy to the host in a single functio