WebAssembly does have bounds checking, you can't write outside the designated memory block.
On 64-bit systems with virtual address space to spare, you can offload bounds checking to MMU by memory mapping 2 GB+ protection zone both below and above the exposed memory region.
If you then limit all pointers/offsets to 32-bit, there should be no direct way to corrupt anything else. You can't reach anything interesting within 32-bit offsets. Of course one can corrupt WebAssembly instance memory all they want, but it won't matter.
Performance and security win.
Left CPU bugs outside consideration, hopefully those can be addressed in WASM codegen. Not like it's that different from current Javascript JIT cases.
The memory block contains all data together in well, a block, thus you can happily overwrite two neighbouring arrays, unless I am missing something here WebAssembly does not have fat pointers.
Funny question, basically with corrupted data anything goes.
For a very extreme convoluted example, maybe that value given back to the JavaScript layer will trigger a patient death by sending the wrong value to their insulin device monitor.
But yeah, code and true call stack will be perfectly safe.
Successful lawsuits against insecure software need to become a common event until most companies actually start paying attention to their technology stack and development processes.
