I don't mean to be a pedant, so someone please correct me if I'm wrong, but I don't think TLB mishandling would result in arbitrary memory access (I suppose in the strictest sense arbitrary can just mean random, but generally I have understood it to imply that the address can be attacker controlled, which a stale TLB wouldn't allow).

Unless you're like Microsoft (from your link) and accidentally leave the page tables writable from userspace for 2 months. But that's not really a TLB error, that's just L-O-L, wow!

Random access is arbitrary access, given enough time. You can try over and over again until you get lucky.

Imagine I'm a user with local shell access trying to read a secret owned by root. Maybe I can't read the secret, but I can do something which makes another program read the secret. If I can make that program swap (perhaps by wasting a bunch of RAM to create memory pressure), and swapping has some probability of triggering a TLB invalidation bug that lets me see the old page, I win, although it might take awhile.

Read-Write-eXecute TLB memory region can be found in JavaScript, Java, Dalvik (Android), and Python.

Modern javascript engines (namely V8) avoid RWX, although last time I checked there's been a backslide as part of WASM implementation.

CPython also no longer appears to create RWX mappings even for ctypes, although you can of course still mmap them manually.

Wow. So V8 actually back to optimizing the entire bytecode region in one fell swoop?

I had thought that such V8 optimization were still occuring (as of Chrome Blink81/SparkPlug) during JavaScript execution of untouched bytecode as a form of overhead reduction of its startup.

https://egbert.net/blog/articles/javascript-jit-engines-time...

I don't know what V8 actually does, but one possible strategy is to have a pair of RW and RX mappings to the same physical pages (or just keep flipping permissions between the two)