Project Fortify, an experimental security project, has identified the following potential security issue.

Overview: A compromised GPU process can trigger an out-of-bounds read in the browser process by supplying an unvalidated content_rect during frame capture. The browser uses these dimensions to construct an SkBitmap without checking if it exceeds the shared memory buffer size, leading to an OOB read during JPEG encoding or painting. This could result in a browser crash or potential information disclosure.

Affected files:

• chrome/browser/ui/thumbnails/background_thumbnail_video_capturer.cc
• chrome/browser/ui/thumbnails/thumbnail_image.cc

Estimated timestamp from git blame: 2026-02-27

Summary

There is a potential out-of-bounds (OOB) read vulnerability in the browser process when handling video frames captured from a compromised GPU process. Implementations of viz::mojom::FrameSinkVideoConsumer in the browser process, specifically BackgroundThumbnailVideoCapturer and BrowserLiveBackgroundController::VideoConsumer, fail to adequately validate the content_rect parameter before using it to size an SkBitmap backed by shared memory.

Vulnerability Details

When the GPU process sends a captured frame via the FrameSinkVideoConsumer::OnFrameCaptured Mojo IPC, it provides a shared memory handle (data), frame metadata (info), and a content_rect.

In BackgroundThumbnailVideoCapturer::OnFrameCaptured (and similarly in BrowserLiveBackgroundController), the code validates that the shared memory mapping size is large enough to hold a frame of info->coded_size. However, it completely ignores info->coded_size when constructing the resulting image. Instead, it derives the SkBitmap’s width and height directly from the unvalidated content_rect boundaries (content_rect.right() and content_rect.bottom()).

// chrome/browser/ui/thumbnails/background_thumbnail_video_capturer.cc
const gfx::Size bitmap_size(content_rect.right(), content_rect.bottom());
SkBitmap frame;
frame.installPixels(
    SkImageInfo::MakeN32(bitmap_size.width(), bitmap_size.height(), ...),
    pixels,
    media::VideoFrame::RowBytes(..., info->coded_size.width()),
    ...);

SkBitmap::installPixels accepts a raw void* for the memory buffer but does not take a buffer_size parameter. It inherently assumes the provided buffer is large enough for the requested height and row bytes. Because the content_rect height can arbitrarily exceed the coded_size height, this creates an SkBitmap that extends far beyond the bounds of the mapped shared memory.

When this SkBitmap is later passed to ThumbnailImage::CompressBitmap and encoded via gfx::JPEGCodec::Encode, the JPEG encoder iterates over the massive height, reading out of bounds into adjacent browser process memory.

Impact

An attacker compromising the GPU process could exploit this to read browser process memory. The OOB data is compressed into a JPEG and displayed in the browser UI (e.g., Tab Hover Cards). Because the compromised GPU process handles compositing the final screen, it can read the rendered pixels and extract the leaked browser memory. Additionally, if the OOB read hits an unmapped guard page, it will cause an immediate browser process crash (Denial of Service).

Suggested Reproduction Steps

Note: These are potential steps to trigger the issue, as the Fortify LLM agent cannot actively run code to provide a working PoC.

1. Compromise the GPU process.
2. Wait for the browser process to request a background tab capture (e.g., user hovers over a background tab) and intercept the FrameSinkVideoConsumer::OnFrameCaptured callback.
3. Send a message with info.coded_size set to a small dimension (e.g., 100x100) and a backing shared memory region of 40,000 bytes.
4. Set content_rect to maliciously large dimensions, e.g., gfx::Rect(0, 0, 100, 10000).
5. The browser process maps the memory, passes the size check (as coded_size matches the buffer), and creates an SkBitmap of size 100x10000.
6. The browser routes the frame to a background thread for JPEG compression, where the encoder reads 9,900 rows out of bounds.

Suggested Fix

Ensure that the dimensions derived from content_rect do not result in a byte size requirement that exceeds the mapped shared memory.

A safe pattern for this already exists in DevToolsEyeDropper::OnFrameCaptured (chrome/browser/devtools/devtools_eye_dropper.cc), which uses computeByteSize to explicitly validate the buffer size against the SkImageInfo before calling installPixels:

auto image_info = SkImageInfo::MakeN32(...);
const size_t row_bytes = media::VideoFrame::RowBytes(...);

// Ensure the unbounded pointer points to enough memory.
CHECK_GE(mapping.size(), image_info.computeByteSize(row_bytes));

frame.installPixels(image_info, ...);

This check should be applied to BackgroundThumbnailVideoCapturer, BrowserLiveBackgroundController::VideoConsumer, and any other implementers of FrameSinkVideoConsumer that manually construct SkBitmaps from content_rect.

Evaluated with Chrome root at commit: bb48272cafb7e24c93f55ef40da398cd206ee651

Results so far have been promising, but there can be wrong deductions. If this proves to be a false positive, please close as WAI; data from false positives will be used to improve accuracy over time. Please feel free to reach out to me if you have concerns or feedback.