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 use-after-free (UAF) vulnerability exists in BrowserView::Show() on Windows. When calling browser_widget_->Show(), synchronous native message dispatch can cause the browser window to be destroyed and free the BrowserView instance. Subsequent accesses to the deleted BrowserView instance result in use-after-free reads and writes.

Affected files:

• chrome/browser/ui/views/frame/browser_view.cc

Estimated timestamp from git blame: 2011-09-19

Potential Vulnerability Details

A potential Use-After-Free (UAF) vulnerability exists in BrowserView::Show() in chrome/browser/ui/views/frame/browser_view.cc. When browser_widget_->Show() is invoked, it delegates to native platform code to display the window. On Windows, this eventually reaches HWNDMessageHandler::Show(), which synchronously dispatches Windows message loops (such as WM_WINDOWPOSCHANGED, WM_SIZE, WM_ACTIVATE) via the native message loop handler.

If a re-entrant callback (such as an observer, native window manager action, or API event) triggers immediate synchronous window destruction during this message dispatch, Widget::CloseNow() or DestroyWindow() is called. Since BrowserWidget owns the BrowserView within its view hierarchy, the deletion of the widget cascades down to invoke ~BrowserView(), deallocating the BrowserView instance (this).

When the synchronous Win32 dispatch stack unwinds and control returns to BrowserView::Show(), the function continues executing with a freed this pointer and no safety checks. It then proceeds to dereference this across several lines, leading to potential memory corruption:

// chrome/browser/ui/views/frame/browser_view.cc:1606-1624
browser_widget_->Show();                                       // Re-entrant native dispatch

browser()->OnWindowDidShow();                                  // Potential UAF read on raw_ptr browser_
...
if (browser_widget_->IsFullscreen() &&                         // Potential UAF read on unique_ptr browser_widget_
    !GetFrameView()->ShouldHideTopUIInFullscreen() && ...      // Potential UAF virtual call via GetFrameView()
    ) { ... }

#if !BUILDFLAG(IS_CHROMEOS)
if (!accessibility_focus_highlight_) {
  accessibility_focus_highlight_ =
      std::make_unique<AccessibilityFocusHighlight>(this);     // Potential UAF write into freed BrowserView slot
}
#endif

Potential Destruction Flow

browser_widget_->Show()
 -> Widget::Show()
  -> HWNDMessageHandler::Show()  [synchronously dispatches WM_ messages]
     [Triggered Close / Destruction Event]
     -> HWNDMessageHandler::HandleDestroyed()
      -> DesktopWindowTreeHostWin::HandleDestroyed()
       -> DesktopNativeWidgetAura::OnHostClosed()
        -> BrowserWidget::OnNativeWidgetDestroyed()
         -> Browser::SynchronouslyDestroyBrowser()
          -> ~Browser()
           -> BrowserView::DeleteBrowserWindow()
            -> browser_widget_.reset()  [deletes BrowserWidget and its child BrowserView]

Suggested Replication Steps

Note: These are potential steps, as our analysis is static and our tooling agent does not have the ability to run functional exploit payloads or compile and execute proof of concepts.

1. From an extension or page, trigger creation of a new browser window in fullscreen state (e.g., chrome.windows.create({state: "fullscreen"})).
2. Introduce an observer or state change listener that synchronously closes or deactivates the window during its initial activation/display message loop.
3. The window destruction path runs synchronously, freeing BrowserView.
4. When browser_widget_->Show() returns, execution accesses the freed BrowserView memory.

Remediation

To prevent this vulnerability, a base::WeakPtr check should be used immediately after the synchronous browser_widget_->Show() call, matching the pattern already used in BrowserView::SetBounds():

auto weak_ptr = weak_ptr_factory_.GetWeakPtr();
browser_widget_->Show();
if (!weak_ptr) {
  return;
}

Evaluated with Chrome root at commit: bf775e5d75cb9e1767e2cd02cc93efa0077d14a5

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.