Flapjack, 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 Use-After-Free (UAF) vulnerability exists in the renderer process when cancelling an active Glic Actor tool. The cancellation sequence synchronously dispatches a DOM mouseup event, allowing a malicious page to detach the frame and destroy the active tool and its executor while they are still on the call stack. Upon return from the event dispatch, the unwinding code accesses the freed objects.

Affected files:

• chrome/renderer/actor/click_tool.cc
• chrome/renderer/actor/tool_executor.cc

Estimated timestamp from git blame: 2025-12-10

Summary

A Use-After-Free (UAF) vulnerability has been identified in the actor::ClickTool and actor::ToolExecutor classes in the renderer process. The vulnerability occurs because the tool cancellation process (ToolExecutor::CancelTool) synchronously dispatches a mouseup event to the Blink engine via ClickDispatcher::DoMouseUpImpl. This synchronous dispatch allows an attacker-controlled JavaScript event listener to detach the frame, which synchronously destroys the RenderFrameImpl and its associated objects, including the ToolExecutor and the active ClickTool. When the synchronous event dispatch returns, the methods on the call stack continue execution on the freed memory.

Technical Details

To trigger this vulnerability, an attacker must win a race condition to ensure that the CancelTool IPC is processed before the 5ms delayed task in ClickDispatcher::DoMouseDown executes. This can be achieved reliably by stalling the renderer main thread.

Suggested steps an attacker might follow:

1. Create a page with an iframe and a target element inside it.
2. Add mousedown and mouseup event listeners to the target element.
3. Trigger the Actor feature to click the element. This causes ToolExecutor::ExecuteTool to invoke ClickTool::Execute, which creates a ClickDispatcher that synchronously fires the mousedown event.
4. In the mousedown JavaScript listener, execute a busy-wait loop for 35 seconds to block the renderer main thread.
5. While the thread is blocked, the browser process’s 30-second kGlicActorPageToolTimeout expires, causing it to send a CancelTool Mojo IPC to the renderer.
6. When the 35-second busy-wait completes, the main thread resumes. The delayed 5ms DoMouseUp task is not yet runnable, so the task scheduler processes the pending CancelTool IPC.
7. ChromeRenderFrameObserver::CancelTool calls tool_executor_->CancelTool(), which chains to ClickTool::Cancel() and then ClickDispatcher::Cancel().
8. Since the 5ms timer hasn’t fired, the mouse is still “down”. ClickDispatcher::Cancel() calls DoMouseUpImpl(), which synchronously dispatches the mouseup event via widget->HandleInputEvent().
9. The attacker’s mouseup listener is executed. The listener calls window.frameElement.remove(), detaching the iframe.
10. Blink synchronously processes the detachment, calling RenderFrameImpl::FrameDetached. This destroys the RenderFrameImpl, which notifies ChromeRenderFrameObserver::OnDestruct, destroying the observer. This implicitly destroys the ToolExecutor, ClickTool, and ClickDispatcher.
11. The attacker uses heap grooming in the mouseup listener to overwrite the freed ToolExecutor chunk.
12. Execution unwinds back to ClickTool::Cancel() at chrome/renderer/actor/click_tool.cc:114, which calls click_dispatcher_.reset() on the freed object.
13. Execution unwinds to ToolExecutor::CancelTool(), which calls ToolFinished() (chrome/renderer/actor/tool_executor.cc:277).
14. Inside ToolFinished() (chrome/renderer/actor/tool_executor.cc:280), the code accesses multiple fields on the freed this pointer and executes std::move(completion_callback_).Run(), leading to potential Remote Code Execution (RCE) in the renderer process.

While ClickDispatcher::DoMouseUpImpl correctly checks !weak_this after returning from HandleInputEvent, its callers (ClickTool and ToolExecutor) do not verify if they were destroyed during the synchronous call.

(Note: These are suggested steps based on static analysis; our tooling does not yet execute code to provide a working PoC.)

Proposed Fix

The objects on the call stack must check for their own destruction after any synchronous call that can execute script. ClickTool::Cancel should use a base::WeakPtr to check its existence before accessing its members. Similarly, ToolExecutor::CancelTool must verify the ToolExecutor is still alive before calling ToolFinished or accessing this.

Evaluated with Chrome root at commit: 2155cb00003ec35716a76ed3246eae995f87b7ff

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.