Wasmtime's Winch compiler backend incorrectly types the result of the table.grow operator for 32-bit tables, tagging it as a 64-bit value instead of 32-bit. This internal state corruption can cause bytes in the host's address space immediately preceding linear memory to be read or written. Since these bytes are typically unmapped memory, Wasmtime aborts the process upon access, resulting in a denial of service. If guard pages before linear memory are disabled, an attacker may leak up to 16 bytes of host memory. The default Cranelift compiler and default guard page settings prevent exploitation under normal configurations. The issue affects Wasmtime versions >= 25.0.0 and < 36.0.7, >= 37.0.0 and < 42.0.2, and >= 43.0.0 and < 44.0.1, and is resolved in versions 36.0.7, 42.0.2, and 43.0.1.

This vulnerability can cause denial of service by crashing the host process when the Winch compiler backend is used with default guard page settings. Additionally, if guard pages are disabled, it may lead to a limited information leak of up to 16 bytes of host memory preceding linear memory. The default Wasmtime configuration using the Cranelift compiler and guard pages is not affected, limiting the practical impact unless the Winch backend is explicitly selected and guard pages disabled.

A fix for this vulnerability is available in Wasmtime versions 36.0.7, 42.0.2, and 43.0.1. Users should upgrade to one of these versions or later to remediate the issue. If upgrading is not immediately possible, ensure that the default Cranelift compiler backend and guard pages before linear memory remain enabled, as these default settings prevent exploitation. Disabling guard pages before linear memory should be avoided to prevent potential information leakage.