Project Fortify, an experimental security project, has identified the following potential security issue. If you’re a feature owner CC-ed on this bug, please do your best to review these reports. Please see https://chromium.googlesource.com/chromium/src/+/main/docs/security/ai-generated-security-bugs-faq.md for more information.

Overview: A potential re-entrancy vulnerability exists in V8’s FutexEmulation where the per-isolate singleton FutexWaitListNode can be double-added to the wait list. This condition is reachable when a worker thread is frozen/paused and a debugger session issues a Runtime.evaluate command, which executes on the unpausable kInternalInspector queue inside a nested event loop. Re-entering Atomics.wait during this execution corrupts the doubly-linked list of wait nodes, potentially leading to a use-after-free or heap out-of-bounds write in the renderer process.

Affected files:

• v8/src/execution/futex-emulation.cc
• third_party/blink/renderer/core/inspector/devtools_session.cc
• third_party/blink/renderer/core/workers/worker_thread.cc
• third_party/blink/renderer/platform/scheduler/worker/worker_scheduler_impl.cc

Estimated timestamp from git blame: 2019-05-14

Root Cause Analysis

In V8, FutexEmulation::WaitSyncImpl utilizes a per-isolate singleton FutexWaitListNode (isolate->futex_wait_list_node()) to manage synchronous Atomics.wait operations. A potential re-entrancy issue in this design allows the same singleton node to be added to the global wait list multiple times, corrupting the intrusive doubly-linked list of waiter nodes.

The execution flow to trigger this condition is as follows:

1. Unpausable Task Queue: WorkerSchedulerImpl maps TaskType::kInternalInspector to unpausable_task_queue_ (third_party/blink/renderer/platform/scheduler/worker/worker_scheduler_impl.cc:215). This queue is initialized without a QueueEnabledVoter (worker_scheduler_impl.cc:64) and is therefore never disabled by PauseImpl() when the worker thread is paused or frozen.
2. Direct IO Dispatch: When a Runtime.evaluate command is sent via chrome.debugger to a worker target, the browser routes it over the IO channel, and the renderer IO thread posts it directly to the kInternalInspector task runner as a nestable task (third_party/blink/renderer/core/inspector/devtools_session.cc:118-128).
3. Interrupt during Wait: While a worker thread is blocked inside Atomics.wait, a lifecycle freeze of the parent page triggers a V8 API interrupt (worker_thread.cc:916-918). This wakes the worker thread from its condition variable. Inside WaitSyncImpl, the thread clears the interrupted_ flag, unlocks the wait list mutex, and calls isolate->stack_guard()->HandleInterrupts() (v8/src/execution/futex-emulation.cc:466-467) with the singleton node still linked on the active wait list.
4. Nested Event Loop: The V8 interrupt handler invokes the Blink freeze callback, which pauses the scheduler and spins a nested event loop (worker_thread.cc:960-964) using Platform::Current()->CreateNestedMessageLoopRunner()->Run(). This runner executes nestable tasks.
5. Re-entrant Execution: The nested event loop processes the pending nestable Runtime.evaluate command, allowing arbitrary JavaScript execution. If this evaluation calls Atomics.wait on a different address, it re-enters WaitSyncImpl with the same singleton node.
6. List Corruption: In production (release) builds where DCHECK_NULL assertions are compiled out, the inner wait overwrites node->wait_location_ and calls AddNode on the already-linked singleton node. When the inner wait times out, it erases the new address entry, leaving the old address entry pointing to the singleton node. When the outer wait subsequently resumes and finishes, its call to RemoveNode is ineffective because node->wait_location_ was altered, leaving a stale pointer in the global wait registry.
7. Heap Exploitation: Interleaving Atomics.waitAsync operations from a separate isolate can cause newly allocated and subsequently freed async waiter nodes to be linked to this stale pointer, resulting in a classic Use-After-Free (UAF) or wild memory write inside the sandboxed renderer process.

Potential Step-by-Step Reproduction Path

(Note: These are potential steps; our tooling has not executed this code to verify execution details.)

1. Establish a Dedicated Worker and pass it a SharedArrayBuffer (SAB).
2. Attach to the worker target using an extension with debugger permissions.
3. Have the worker thread enter a sleep state by calling Atomics.wait(new Int32Array(sab), 0, 0) on the first index.
4. Initiate a freeze transition of the worker’s parent context, prompting V8 to request an API interrupt via the StackGuard.
5. The worker thread wakes from its condition variable and enters a nested event loop inside V8’s HandleInterrupts() with the singleton waiter node still linked.
6. Via the attached debugger, execute the command Runtime.evaluate on the worker target, passing Atomics.wait(new Int32Array(sab), 1, 0, 100) to trigger a wait on the second index.
7. The nested run loop processes this task, re-entering WaitSyncImpl and double-adding the singleton node.
8. Allow the inner wait to time out (100ms) and the parent context to resume from freeze. The outer wait resumes and terminates, leaving a stale pointer to the singleton node on the first index’s wait list.
9. Issue an Atomics.waitAsync from a separate isolate on the first index to allocate and link an async node. When that async node is subsequently freed, walking or manipulating the wait list results in a potential Use-After-Free.

Suggested Fix

To remediate this issue, consider implementing one of the following changes:

1. Introduce a re-entrancy check within FutexEmulation::WaitSyncImpl that throws a RangeError or TypeError if a synchronous wait is initiated while the isolate’s singleton FutexWaitListNode is already in a waiting_ state.
2. Ensure that any DevTools-initiated script evaluations on frozen worker threads (via Runtime.evaluate) are rejected or deferred if V8 is currently suspended inside an active HandleInterrupts() frame originating from a WaitSyncImpl state.

Evaluated with Chrome root at commit: 84065d9121f6e48f67755f0ae963cc09617e5c85

Results so far have been promising, but there can be wrong deductions. Feel free to adjust as follows:

• If you are familiar with the severity guidelines, you may adjust the severity.
• If this is a false positive, and there’s no work to be done, please close as WAI.
• If there is work to do here but not a vulnerability, please change the issue type to Task/Bug/FR.

Data from false positives will be used to improve accuracy over time. And please feel free to reach out to me directly if you have concerns or feedback on the project.