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: The OverscrollRefresh class on Android fails to initialize its viewport_width_ member variable in its constructors, leading to an uninitialized heap read. A compromised renderer can potentially exploit this as a side-channel to leak data from the browser process heap.

Affected files:

• ui/android/overscroll_refresh.cc
• ui/android/overscroll_refresh.h
• content/browser/android/overscroll_controller_android.cc
• content/browser/renderer_host/render_widget_host_view_android.cc

Estimated timestamp from git blame: 2019-04-18

Root Cause Analysis

In ui/android/overscroll_refresh.cc, the viewport_width_ member variable of the OverscrollRefresh class is not initialized in either of its constructors. Since OverscrollRefresh objects are allocated on the browser process heap, this variable will initially contain stale data from previous allocations.

OverscrollRefresh::OverscrollRefresh(OverscrollRefreshHandler* handler,
                                     float edge_width)
    : scrolled_to_top_(true),
      scrolled_to_bottom_(false),
      // ...
      edge_width_(edge_width),
      handler_(handler) {            // viewport_width_ is NOT initialized
  DCHECK(handler);
}

The variable is only assigned a value in OnFrameUpdated, which is triggered when the browser receives compositor frame metadata from the renderer.

Vulnerability and Side-Channel Leak

A compromised renderer (e.g., via a post-renderer-RCE) can withhold its first compositor frame metadata indefinitely, ensuring that OnFrameUpdated is never called and viewport_width_ remains uninitialized.

When a user performs a swipe gesture, the browser executes OverscrollRefresh::OnOverscrolled if the renderer sends a DidOverscroll IPC. In OnOverscrolled, the uninitialized viewport_width_ is read during horizontal overscroll processing at ui/android/overscroll_refresh.cc:110:

} else if (in_x_direction) {
  DCHECK_GE(viewport_width_, 0);
  bool scroll_from_edge = scroll_begin_x_ < edge_width_ ||
                          viewport_width_ - scroll_begin_x_ < edge_width_;

The boolean scroll_from_edge determines whether the browser activates the overscroll navigation effect. If activated, the browser process suppresses subsequent input events to the renderer for the duration of that gesture sequence.

By observing whether it continues to receive input event IPCs, a compromised renderer can determine the result of the comparison involving the uninitialized heap data. This establishes a side-channel that leaks approximately one bit of browser process heap information per user swipe gesture. While the leak rate is constrained by user interaction, it allows reading values from the unsandboxed browser process heap.

Potential Reproduction Steps

Note: These steps are based on static analysis of the Chromium source code.

1. From a compromised renderer, navigate to an attacker-controlled page.
2. In the renderer, suppress the submission of the first compositor frame metadata.
3. Wait for the user to perform a horizontal swipe gesture.
4. From the renderer, trigger a horizontal overscroll signal (e.g., via DidOverscroll).
5. Monitor the input event stream in the renderer. If GestureScrollUpdate events stop arriving, the overscroll effect was activated, indicating that the garbage value in viewport_width_ satisfied the edge-check condition.

Suggested Fix

Initialize viewport_width_ to 0 in the OverscrollRefresh constructors or provide an in-class initializer in ui/android/overscroll_refresh.h.

float viewport_width_ = 0.f;

Evaluated with Chrome root at commit: 1a8d40fc44df2088d5945c0bf53584038aa1614a

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.