Ah that example makes it clear. I'll ignore the obvious issue of libpng being written in JS having a similar problem. So the libpng WASM would have its memory instance (probably imported from the caller) and functions would reference the memory. It's not like with regular RAM where if you overflowed a mem write that it would write executable instructions. Code is different from memory. There is no eval. There is a "call_indirect" which can call a function by a dynamic function index, but what would a dangerous function that libpng imported? You can't execute memory or anything.

I can see some site DOSing though where you use the equivalent of a png-bomb to blow up CPU from the parser, but that is any not-meticulously written client-side parser of untrusted input.

So while you can toy with memory and maybe even affect the function pointer before a successive indirect call, it's not near as dangerous to the outside-of-wasm world as raw CPU instructions. I can see an issue where the caller that imports libpng and exports his memory to it might have something secret in that memory...hopefully multi-memory and GC-like-structs and what not can make passing and manipulating large blocks more like params than shared mem (and all of shared mem's faults).

It's a bit extreme but the reality is that a lot of production libraries tend to pull in imports that are as dangerous as eval, because the scope of the library is enormous, or it's actively supposed to interact with the DOM or JS. At that point, if someone can more trivially exploit it with a double free or buffer overflow, you've increased your security risk relative to JS (because overflowing a Uint8Array is basically never going to result in arbitrary function invocation)

The way function addresses are sequential in wasm tables (and deterministic) also means it is probably easier to get to the function you want once you get code execution.