On x64, Liftoff makes the assumption that 32-bit values held in 64-bit registers are always zero extended. With debug code, we check that invariant at loads, stores and i64-to-i32 conversions. The invariant is maintained within Liftoff code.

I just hit a bug in the pspdfkit benchmark (https://pspdfkit.com/webassembly-benchmark/), where we wrongly report a wasm OOB memory access. This happens because Turbofan sometimes passes 32-bit arguments that are not zero-extended.

In order to fix this and protect against future instances of the same bug, I see three action items here:

1) Fix the bug, with two options ((a) is my preference):
 a) Fix it in Turbofan, ensure that 32-bit values are always zero-extended if passed as argument in a 64-bit register.
 b) Fix it in Liftoff by sanitizing all 32-bit parameters.

2) Extend the fuzzer(s) to test mixed Turbofan/Liftoff execution. We currently only test both in isolation.

3) Fix the wasm trap handler such that only accesses within 8GB of a wasm memory start are caught; other accesses should be reported as SEGV.

This bug tracks AI (1). I will open separate bugs for (2) and (3).

This bug has high severity, as it allows read and write access to arbitrary accesses. Low impact though, as Liftoff is only enabled in M69, so it did not hit beta or stable yet.

Making this an M69 beta blocker; we should be able to fix this within a few days.