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 out-of-bounds read can occur in the renderer process during video capture when custom strides are used. A compromised GPU process could send a video frame with custom strides smaller than the minimum row bytes for the specified width, bypassing the checks in VideoCaptureImpl. This can lead to an out-of-bounds read inside libyuv::I420Copy.

Affected files:

• third_party/blink/renderer/platform/video_capture/video_capture_impl.cc
• media/base/video_frame.cc

Estimated timestamp from git blame: 2018-09-18

Description

A potential out-of-bounds read vulnerability has been identified in VideoCaptureImpl in the renderer process.

In VideoCaptureImpl::ProcessBuffer (third_party/blink/renderer/platform/video_capture/video_capture_impl.cc:285-331), when a video frame is processed with custom strides via the kUnsafeShmemRegion handle path, the code verifies that the backing shared memory span is large enough to contain rows * stride for each plane. However, it does not validate that the custom stride is at least as large as the minimum required bytes per row for the given width (i.e., stride >= VideoFrame::RowBytes(...)).

Since VideoFrame::WrapExternalYuvData does not perform further validation of strides against width, a VideoFrame can be created with an extremely small stride but a large width. Subsequent consumers of this frame, such as WebMediaPlayerMSCompositor::CopyFrame (which utilizes libyuv::I420Copy), copy data based on the frame’s logical width. This causes memcpy operations to read past the boundary of the shared memory mapping.

Suggested Attack Flow (Potential Steps)

Note: The following are potential steps based on source code analysis; our analysis tooling does not have the ability to execute code to verify this.

1. A compromised GPU process calls OnFrameCaptured via the viz::mojom::FrameSinkVideoConsumer remote.
2. The IPC payload specifies a tiny shared memory region (e.g., 8 bytes), a large frame size (e.g., coded_size = {8192, 4}), and invalid strides (e.g., strides = {1, 1, 1, 0}).
3. The browser process relays this frame to the renderer process without validation.
4. The renderer process maps the 8-byte shared memory buffer in BufferContext.
5. In VideoCaptureImpl::ProcessBuffer, the validation Rows * stride checks pass because 4 * 1 = 4 (Y plane) and 2 * 1 = 2 (U/V planes) fit within the 8-byte buffer.
6. The VideoFrame is created with a logical width of 8192 and strides of 1.
7. When the video is paused or copied in WebMediaPlayerMSCompositor::ReplaceCurrentFrameWithACopy, libyuv::I420Copy attempts to copy 8192 bytes per row.
8. This results in an out-of-bounds read of up to 32 KiB from the renderer’s heap.

Code References

• Vulnerable Code Location: third_party/blink/renderer/platform/video_capture/video_capture_impl.cc:285-331

• Missing Check Reference: In contrast, the sibling FitsInContiguousBufferOfSize check (used by the non-strides path) correctly enforces this check: media/base/video_frame_layout.cc:254

  size_t row_bytes = VideoFrame::RowBytes(plane_idx, format_, coded_size_.width());
  if (plane.stride < row_bytes) {
    return false;
  }
  

Suggested Fix

To mitigate this issue, validate that custom strides are not less than the minimum required row bytes for the specified width.

For example, in third_party/blink/renderer/platform/video_capture/video_capture_impl.cc, add the following validation inside the strides branch:

for (size_t i = 0; i < 3; ++i) {
  size_t row_bytes = media::VideoFrame::RowBytes(
      i, video_frame_init_data.ready_buffer->info->pixel_format,
      video_frame_init_data.ready_buffer->info->coded_size.width());
  if (video_frame_init_data.ready_buffer->info->strides->stride_by_plane[i] < row_bytes) {
    return false;
  }
}

Evaluated with Chrome root at commit: 87214e6721f6c34afd9181b80769a24c0c601c50

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.