No. Marking memory as executable is a native machine level capability (as in x86_64 assembly machine instructions). Wasm is a stack machine interpreter that can read only Wasm binaries. The binary format is essentially just a compressed/minimized form of the bytecode format, which used to essentially be an AST of the original source code, but now I believe they modified it a bit to be more analogous to hypothetical machine code, but still abstracted. The Wasm interpreter does not understand x86 or ARM or whatever machine code it's fed it and rightly so. If that was possible, anyone could just send over a buffer to the browser to execute whatever they want.

That's what I thought. Then that's one whole category of exploits that no longer applies, no?

Yes, assuming there's no flaws in the interpreter. But they're all moving full steam ahead in the browsers right now, so imagine it's deemed as safe as javascript. The current push is to divvy up the permissions of certain resources such as sockets and filesystem (browser code don't have filesystem access) and make an API to ensure that modules don't overstep their granted permissions. It'll probably look a lot like node and npm, where you could add a module to your source and know that it can't access things it shouldn't. Pretty exciting stuff. It's a true merger of all languages together under one runtime.

That's true, but that's a class of exploits that is mostly impossible anyway (except in an embedded environment). Most systems that have an MMU ensure that no page is both writeable and executable, meaning you can't inject code. This forces attackers to use ROP.