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 potential heap Use-After-Free (UAF) vulnerability exists in the Linux/X11 browser process within x11::GeometryCache::GetBoundsPx(). The issue is caused by synchronous dispatching of X11 replies which can trigger a callback chain that destroys the GeometryCache object while its methods are still executing on the stack.

Affected files:

• ui/gfx/x/geometry_cache.cc
• ui/ozone/platform/x11/x11_window.cc
• ui/aura/window_tree_host_platform.cc

Estimated timestamp from git blame: 2023-12-01

Summary

A potential heap Use-After-Free vulnerability has been identified in the browser process on Linux/X11. The vulnerability occurs in x11::GeometryCache::GetBoundsPx() because it performs synchronous X11 reply dispatching that can trigger a recursive callback chain resulting in the destruction of the GeometryCache instance while its code is still executing.

Root Cause Analysis

In ui/gfx/x/geometry_cache.cc, the GetBoundsPx() function ensures that parent and geometry information is retrieved by calling DispatchNow() on pending X11 futures:

gfx::Rect GeometryCache::GetBoundsPx() {
  if (!have_parent_) {
    parent_future_.DispatchNow();      // [1] Synchronous dispatch
  }
  CHECK(have_parent_);
  if (!have_geometry_) {
    geometry_future_.DispatchNow();    // [2] Synchronous dispatch
  }
  CHECK(have_geometry_);               // [3] Potential UAF read
  if (!parent_) {
    return geometry_;                  // [4] Potential UAF read
  }
  // ...
}

DispatchNow() (in ui/gfx/x/future.cc) is synchronous; it waits for the X11 response and immediately executes the associated callback. For the GeometryCache instance owned by an X11Window, the response callback eventually triggers X11Window::OnBoundsChanged via NotifyGeometryChanged().

X11Window::OnBoundsChanged propagates the bounds update to its delegate, typically WindowTreeHostPlatform. In ui/aura/window_tree_host_platform.cc, the OnBoundsChanged implementation explicitly warns that propagating these changes can synchronously destroy the host:

void WindowTreeHostPlatform::OnBoundsChanged(const BoundsChange& change) {
  // ...
  auto weak_ref = GetWeakPtr();
  OnHostMovedInPixels();
  // Changing the bounds may destroy this.
  if (!weak_ref) return;
  // ...
}

If an observer of these bounds changes (e.g., during window snapping or closure) causes the Widget to close, the X11Window is destroyed. The X11Window destructor resets its geometry_cache_ (a std::unique_ptr), which deletes the GeometryCache object. When the stack unwinds back to GetBoundsPx() from the synchronous DispatchNow() call, the function continues to access members of the now-freed this object at locations [3], [4], and during subsequent logic.

Potential Attack Vector

An attacker could potentially trigger this by influencing window destruction timing during bounds updates. For example, by carefully timed window manipulation (like snapping a window into a tab strip or closing a popup window) that triggers a synchronous bounds check while X11 replies are pending. Since this occurs in the browser process, successful exploitation could lead to arbitrary code execution with the user’s privileges.

Impact

This is a browser-process heap UAF. The affected members in GeometryCache (have_geometry_, parent_, and geometry_) are not protected by MiraclePtr/BackupRefPtr. The browser process is unsandboxed, making this a critical security concern.

Suggested Fix

The GetBoundsPx() method should protect itself against object destruction during DispatchNow() calls. This can be achieved by using a base::WeakPtr to check for object validity after each synchronous dispatch:

gfx::Rect GeometryCache::GetBoundsPx() {
  auto weak_this = weak_ptr_factory_.GetWeakPtr();
  if (!have_parent_) {
    parent_future_.DispatchNow();
    if (!weak_this) return {};
  }
  CHECK(have_parent_);
  if (!have_geometry_) {
    geometry_future_.DispatchNow();
    if (!weak_this) return {};
  }
  CHECK(have_geometry_);
  // ...
}

Alternatively, avoiding synchronous dispatch in this context or ensuring that bounds change notifications are always debounced/asynchronous would mitigate the risk.

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.