Wasmtime is a runtime for WebAssembly. From 32.0.0 to before 36.0.7, 42.0.2, and 43.0.1, Wasmtime's Cranelift compilation backend contains a bug on aarch64 when performing a certain shape of heap accesses which means that the wrong address is accessed. When combined with explicit bounds checks a guest WebAssembly module this can create a situation where there are two diverging computations for the same address: one for the address to bounds-check and one for the address to load. This difference in address being operated on means that a guest module can pass a bounds check but then load a different address. Combined together this enables an arbitrary read/write primitive for guest WebAssembly when accesssing host memory. This is a sandbox escape as guests are able to read/write arbitrary host memory. This vulnerability has a few ingredients, all of which must be met, for this situation to occur and bypass the sandbox restrictions. This miscompiled shape of load only occurs on 64-bit WebAssembly linear memories, or when Config::wasm_memory64 is enabled. 32-bit WebAssembly is not affected. Spectre mitigations or signals-based-traps must be disabled. When spectre mitigations are enabled then the offending shape of load is not generated. When signals-based-traps are disabled then spectre mitigations are also automatically disabled. The specific bug in Cranelift is a miscompile of a load of the shape load(iadd(base, ishl(index, amt))) where amt is a constant. The amt value is masked incorrectly to test if it's a certain value, and this incorrect mask means that Cranelift can pattern-match this lowering rule during instruction selection erroneously, diverging from WebAssembly's and Cranelift's semantics. This incorrect lowering would, for example, load an address much further away than intended as the correct address's computation would have wrapped around to a smaller value insetad. This vulnerability is fixed in 36.0.7, 42.0.2, and 43.0.1.
The vulnerability results from miscompilation of memory access instructions with the pattern load(iadd(base, ishl(index, amt))), where amt is a constant. Cranelift incorrectly masks the amt value during instruction selection, causing the same memory access operation to compute two different addresses: one used for bounds checking and another actually loaded. The guest module can thus pass the bounds check and then access a completely different host memory address. The bug only manifests on aarch64 architecture, with 64-bit linear WebAssembly memory spaces enabled (or Config::wasm_memory64 option) and when both Spectre protections and signals-based-traps are disabled.
An attacker controlling a guest WebAssembly module can read and write arbitrary areas of the host process memory, resulting in complete sandbox escape and potential takeover of the host.
Update Wasmtime to version 36.0.7, 42.0.2, or 43.0.1. As a temporary workaround: enabling Spectre mitigation (enabled by default) or signals-based-traps prevents generation of vulnerable code — however, the vendor patch should be installed as soon as possible.
Bytecode Alliance Wasmtime versions from 32.0.0 to (excluding) 36.0.7, 42.0.2, and 43.0.1; affects only aarch64 architecture with 64-bit linear WebAssembly memory spaces and disabled Spectre mitigations or signals-based-traps.
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:XBytecodealliance Wasmtime
APPBytecodealliance43.0.032.0.0 – 36.0.7 (excl.)37.0.0 – 42.0.2 (excl.)
Related vulnerabilities
Wasmtime (Winch): ucieczka z sandboxa WebAssembly, dostęp do pamięci hosta
Błąd obliczania adresu w Cranelift (x86_64) — zapis/odczyt poza obszarem pamięci WebAssembly
Wasmtime is a standalone runtime for WebAssembly. Prior to versions 2.0.2 and 1.0.2, there is a bug in Wasmtim...
Wasmtime is a standalone JIT-style runtime for WebAssembly, using Cranelift. There is a use after free vulnera...
Wasmtime to runtime dla WebAssembly. W wersjach od 30.0.0 do 36.0.8, 43.0.2 i 44.0.1 logika alokacji pamięci d...