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 RenderWidgetHostViewAura::ShowWithVisibility on Windows due to a missing lifetime check. When calling ShowImpl, a nested message loop can be spun during parent or bounds updates of the legacy window, allowing re-entrant window destruction events to delete the view. Upon returning from ShowImpl, the function dereferences members of the already-freed this object.

Affected files:

• content/browser/renderer_host/render_widget_host_view_aura.cc

Estimated timestamp from git blame: 2021-01-28

Summary

A potential Use-After-Free (UAF) vulnerability exists in the browser process of Chromium on Windows. The issue is located in RenderWidgetHostViewAura::ShowWithVisibility inside content/browser/renderer_host/render_widget_host_view_aura.cc. When ShowImpl is executed, it can transitively call Win32 windowing APIs that synchronously dispatch messages and spin a nested message loop. If a window close or destruction event is handled during this nested loop, the RenderWidgetHostViewAura instance is deleted. While intermediate functions contain safety guards, the parent method ShowWithVisibility fails to check if the instance is still alive before dereferencing this.

Technical Analysis

In content/browser/renderer_host/render_widget_host_view_aura.cc, the method RenderWidgetHostViewAura::ShowWithVisibility executes the following sequence:

void RenderWidgetHostViewAura::ShowWithVisibility(
    PageVisibilityState page_visibility) {
  ...
  window_->Show();
  ShowImpl(page_visibility);
#if BUILDFLAG(IS_WIN)
  if (page_visibility != PageVisibilityState::kVisible &&
      legacy_render_widget_host_HWND_) {
    legacy_render_widget_host_HWND_->Hide();
  }
#endif  // BUILDFLAG(IS_WIN)
}

The call to ShowImpl(page_visibility) eventually routes to NotifyHostAndDelegateOnWasShown, which triggers UpdateLegacyWin() on Windows. Inside UpdateLegacyWin(), Win32 API calls such as ::SetParent or ::SetWindowPos are performed:

if (legacy_render_widget_host_HWND_) {
  base::WeakPtr<RenderWidgetHostViewAura> weak_this(
      weak_ptr_factory_.GetWeakPtr());
  legacy_render_widget_host_HWND_->UpdateParent(GetHostWindowHWND());
  if (!weak_this) { return; }
  legacy_render_widget_host_HWND_->SetBounds(window_->GetBoundsInRootWindow());
  if (!weak_this) { return; }

As noted in the developer comments, both UpdateParent and SetBounds can synchronously dispatch window messages and spin a nested event loop. If a window close/destruction event is dispatched during this nested pump, the re-entrant dispatch reaches RenderWidgetHostViewAura::OnWindowDestroyed, which executes delete this;.

Although UpdateLegacyWin and intermediate functions correctly utilize a WeakPtr guard to return immediately upon destruction, the top-level ShowWithVisibility method lacks this protection. After ShowImpl() returns, the stack unwinds back to ShowWithVisibility, which immediately attempts to read legacy_render_widget_host_HWND_ from the freed this object, resulting in a Use-After-Free.

Because this is a bare stack reference at the call site, MiraclePtr (BackupRefPtr) does not protect against or mitigate this UAF.

Potential Trigger Steps

Note: These are potential, theoretical steps as our automated tooling does not have the capability to run code.

1. Open a same-origin popup window using window.open().
2. Force a page visibility transition to a non-visible but active state, such as PageVisibilityState::kHiddenButPainting (e.g., via tab capture or background Picture-in-Picture).
3. Race this visibility change with a window close event (e.g., by sending a widget close IPC from a compromised renderer or calling window.close() on the popup) so that the destruction message is processed during the synchronous Win32 API calls (::SetParent or ::SetWindowPos) inside UpdateLegacyWin().
4. When the nested loop terminates, the call stack unwinds to ShowWithVisibility, which dereferences the freed RenderWidgetHostViewAura instance when evaluating legacy_render_widget_host_HWND_.

Suggested Fix

Introduce a WeakPtr check in ShowWithVisibility immediately after returning from ShowImpl to prevent dereferencing the deleted this pointer:

void RenderWidgetHostViewAura::ShowWithVisibility(
    PageVisibilityState page_visibility) {
  UpdateScreenInfo();

  if (!window_->GetLocalSurfaceId().is_valid()) {
    window_->AllocateLocalSurfaceId();
    SynchronizeVisualProperties(cc::DeadlinePolicy::UseDefaultDeadline(),
                                window_->GetLocalSurfaceId());
  }

  base::WeakPtr<RenderWidgetHostViewAura> weak_this(
      weak_ptr_factory_.GetWeakPtr());

  window_->Show();
  ShowImpl(page_visibility);

#if BUILDFLAG(IS_WIN)
  if (!weak_this) {
    return;
  }
  if (page_visibility != PageVisibilityState::kVisible &&
      legacy_render_widget_host_HWND_) {
    legacy_render_widget_host_HWND_->Hide();
  }
#endif  // BUILDFLAG(IS_WIN)
}

Evaluated with Chrome root at commit: a2bea94528f4bd6cc57739c43fa3bb890b8367d3

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.