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 without the Chrome Security team. Please see https://chromium.googlesource.com/chromium/src/+/main/docs/security/ai-generated-security-bugs-faq.md for more information.

Overview: A re-entrancy vulnerability in the Windows-specific legacy window initialization can lead to a Use-After-Free (UAF) in the browser process. Synchronous message dispatch during window creation or COM activation allows the object to be destroyed before the initialization function completes, resulting in memory corruption when execution resumes.

Affected files:

• content/browser/renderer_host/legacy_render_widget_host_win.cc
• content/browser/renderer_host/legacy_render_widget_host_win.h

Estimated timestamp from git blame: 2026-01-29

Summary

A potential Use-After-Free (UAF) vulnerability exists in LegacyRenderWidgetHostHWND::InitOrDeleteSelf within content/browser/renderer_host/legacy_render_widget_host_win.cc. The method performs several operations that synchronously dispatch window messages or pump the Windows message loop. If the LegacyRenderWidgetHostHWND object is destroyed during one of these re-entrant calls, the method continues to execute on a freed this pointer, leading to arbitrary writes and virtual function calls in the unsandboxed browser process.

Root Cause Analysis

In LegacyRenderWidgetHostHWND::InitOrDeleteSelf, several calls are known to be re-entrant on Windows:

1. WindowImpl::Init (Line 221): Calls ::CreateWindowEx, which synchronously dispatches messages like WM_CREATE and WM_GETMINMAXINFO to the window procedure.
2. NotifyWinEvent (Line 271): A synchronous API that can trigger WinEvent hooks or cause accessibility clients (like screen readers) to query the window via WM_GETOBJECT synchronously.
3. DirectManipulationHelper::CreateInstance (Line 292): Performs COM operations, including IDirectManipulationManager::Activate, which is documented to potentially dispatch messages and pump the loop.

Unlike other re-entrancy-prone methods in the same class (such as UpdateParent, OnKeyboardRange, and OnMouseRange), InitOrDeleteSelf lacks base::WeakPtr guards. If a destruction request for the parent window (e.g., a renderer-initiated window.close()) is processed during these synchronous calls, the LegacyRenderWidgetHostHWND (a child window) is recursively destroyed. This reaches OnNCDestroy, which executes delete this;. When control returns to InitOrDeleteSelf, the method resumes and performs multiple writes to member variables (e.g., ax_fragment_root_, window_tree_host_prop_) and a virtual call via host_->UpdateTooltip() on freed memory.

Potential Impact

This is a high-severity UAF in the unsandboxed browser process. An attacker who can control the heap layout (e.g., via a compromised renderer) could potentially occupy the freed memory during the re-entrant loop and hijack the subsequent virtual calls or writes to achieve arbitrary code execution (RCE) in the context of the browser process.

Suggested Reproductions Steps

Note: These steps are theoretical as our analysis is based on static code review.

1. On a Windows system with an active WinEvent client (e.g., Narrator or a custom hook), navigate to a page that opens a new popup via window.open().
2. Immediately trigger a close operation on the popup (e.g., window.close()) to queue a destruction task.
3. If the destruction task is processed during the synchronous dispatch inside InitOrDeleteSelf (specifically during the NotifyWinEvent or DirectManipulationHelper::CreateInstance calls), a UAF should occur when the function resumes.
4. In a build with AddressSanitizer (ASan), this would manifest as a heap-use-after-free with the free stack at LegacyRenderWidgetHostHWND::OnNCDestroy and the use stack at LegacyRenderWidgetHostHWND::InitOrDeleteSelf.

Recommended Fix

The fix should follow the pattern already used in UpdateParent. Utilize the existing msg_handler_weak_factory_ to create a WeakPtr guard before any re-entrant calls and verify the object’s liveness before proceeding.

Example fix for re-entrant points:

base::WeakPtr<LegacyRenderWidgetHostHWND> ref(msg_handler_weak_factory_.GetWeakPtr());
NotifyWinEvent(...);
if (!ref) return false;

Evaluated with Chrome root at commit: b3153093eb3c78c3e88ccf562bcbc20437a04b0e

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.