VULNERABILITY DETAILS
Please provide a brief explanation of the security issue.

See https://crbug.com/v8/6841

WebAssembly can use signal handlers to catch out of bounds access and recover by throwing a JavaScript exception. This requires metadata about what instruction might fault and a landing pad for each instruction. We found a case where the metadata was not removed when a Wasm instance was collected which could lead to another instance incorrectly matching stale data. This could lead to an out of bounds access leading to a jump to an unexpected location, which could potentially be attacker-controlled.


VERSION
Chrome Version: 62 Beta
Operating System: Linux x64 only

REPRODUCTION CASE

In a V8 checkout:

./out.gn/x64.debug/d8 --test --random-seed=-976563914 --stress-opt --always-opt --nohard-abort test/wasm-spec-tests/tests/memory_trap.js --wasm-trap-handler --stress-runs=5


I haven't actually exploited the bug, but it seems likely to be exploitable.

Suppose we had some compiled Wasm that looked kind of like this:

0: load memory
...
...
13: throw OutOfBoundsException

The handler data table would have an entry for (0, 13), which means if the exception at offset 0 faults, then jump to offset 13 to throw the exception.

If this entry leaked (by destroying an instance and re-instantiating the same module), and then later we compiled a function that generated code like:

0: load memory
...
...
12: load immediate

Then if the immediate was at offset 13, a fault would lead to whatever value was in the immediate field being executed as code. This would only be about 4 bytes of attacker-controlled code, but this is probably enough to build more interesting exploits.