I was struggling to figure out how this could even be exploited. Following a trail of links led to <https://v8.dev/blog/control-flow-integrity#corrupted-syscall

I was struggling to figure out how this could even be exploited. Following a trail of links led to <https://v8.dev/blog/control-flow-integrity#corrupted-syscall-arguments https://v8.dev/blog/control-flow-integrity#corrupted-syscall...>, which motivated the API. It gives the example that "if a thread calls munmap on a corrupted pointer, the attacker could unmap read-only pages and a consecutive mmap call can reuse this address, effectively adding write permissions to the page." So, a hypotetical attack would involve 1) Corrupt a pointer passed to munmap, such that it points to some believed-executable part of the code (e.g. the MPEG decompression library code, or something like that). 2) Cause a future `mmap` to reuse that page with writable permissions, and in particular have the returned page be one that is eventually destined for being marked executable (e.g. the caller should be the JIT compiler). 3) Modify the writable page to control code you want at a known address (e.g. by having the JIT emit code you want, or by having another vulnerability that writes to this address). 4) Have the target page marked executable (e.g. by finishing the JIT compilation). 5) Finally, call the executable page (e.g. attempt to decompress an MPEG file). In the absence of already having arbitrary code execution (which would make the whole process moot), this whole thing requires a JIT compiler (since it has to already contain a call to `mprotect` that sets a page executable), and either the JIT compiler has a bug or a separate thread performs step 3. Are there any example of this kind of attack actually happening? Is there a simpler attack I'm not seeing?