GHSA-vc8c-j3xm-xj73

On x86-64 platforms with AVX Wasmtime's compilation of the f64.copysign WebAssembly instruction with Cranelift may load 8 more bytes than is necessary. When [signals-based-traps] are disabled this can result in a uncaught segfault due to loading from unmapped guard pages. With guard pages disabled it's possible for out-of-sandbox data to be loaded, but unless there is another bug in Cranelift this data is not visible to WebAssembly guests.

Details

The f64.copysign operator, when operating on a value loaded from a memory (for example with f64.load), compiles with Cranelift to code on x86-64 with AVX that loads 128 bits (16 bytes) rather than the expected 64 bits (8 bytes) from memory. When the address is in-bounds for a (correct) 8-byte load but not an (incorrect) 16-byte load, this can load beyond memory by up to 8 bytes. This can result in three different behaviors depending on Wasmtime's configuration:

1. If guard pages are disabled then this extra data will be loaded. The extra data is present in the upper bits of a register, but the upper bits are not visible to WebAssembly guests. Actually witnessing this data would require a different bug in Cranelift, of which none are known. Thus in this situation while it's something we're patching in Cranelift it's not a security issue.
2. If guard pages are enabled, and [signals-based-traps] are enabled, then this operation will result in a safe WebAssembly trap. The trap is incorrect because the load is not out-of-bounds as defined by WebAssembly, but this mistakenly widened load will load bytes from an unmapped guard page, causing a segfault which is caught and handled as a Wasm trap. In this situation this is not a security issue, but we're patching Cranelift to fix the WebAssembly behavior.
3. If guard pages are enabled, and [signals-based-traps] are disabled, then this operation results in an uncaught segfault. Like the previous case with guard pages enabled this will load from an unmapped guard page....