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 type truncation from size_t to int when handling video frame strides allows a compromised renderer to bypass memory safety checks in the GPU process. Specifically, crafted strides can trigger signed integer wraparound, causing buffer bounds checks to pass incorrectly. This results in out-of-bounds memory reads that can be leaked via encoded video bitstreams.

Affected files:

• media/gpu/chromeos/video_frame_resource.cc
• media/base/video_frame.cc
• media/gpu/chromeos/libyuv_image_processor_backend.cc
• media/mojo/mojom/video_frame_mojom_traits.cc

Estimated timestamp from git blame: 2024-11-19

Summary

A potential vulnerability in the ChromeOS video processing pipeline allows a compromised renderer to disclose memory from the privileged GPU process. The issue arises from a size_t to int truncation when handling video frame strides, combined with modular signed integer arithmetic that can bypass internal buffer safety checks.

Root Cause Analysis

The primary issue exists in the interaction between media::VideoFrame and media::VideoFrameResource (used primarily on ChromeOS). While the underlying VideoFrameLayout correctly stores plane strides as size_t (64-bit on 64-bit architectures), several accessors and internal processing functions truncate these values to 32-bit signed int before use.

Specifically:

1. VideoFrameResource::stride(size_t plane) (in media/gpu/chromeos/video_frame_resource.cc) returns an int, while the underlying VideoFrame::stride() returns a size_t (up to 64 bits).
2. VideoFrame::GetVisibleDataInternal() (in media/base/video_frame.cc) truncates the stride to a local int plane_stride before calculating the visible plane size for bounds checking.

Because Chromium is compiled with -fno-strict-overflow, signed integer arithmetic follows modular wraparound rules. An attacker can provide a frame with a logical stride of 0x80000000 (2GB), which truncates to INT_MIN (-2147483648) when converted to a signed 32-bit int. In the calculation for the visible plane size:
visible_plane_size = plane_stride * (rows - 1) + row_bytes
If the frame has an odd number of visible rows (e.g., 3), the term INT_MIN * 2 wraps exactly to 0 in 32-bit signed modular arithmetic. This results in a small, positive visible_plane_size, causing the base::span::subspan() memory safety check to pass even though the stride is logically incorrect.

Potential Attack Vector (Suggested Steps)

1. Compromise Renderer: The attacker starts from a compromised renderer process.
2. Mojo Communication: The attacker utilizes the mojom::VideoEncodeAccelerator Mojo interface to send a crafted VideoFrame to the GPU process.
3. Craft Malicious Frame: The attacker prepares a STORAGE_SHMEM or STORAGE_DMABUFS frame with an odd visible height (e.g., 3), a stride of 0x80000000, and a shared memory region large enough (approx. 4.1GB) to satisfy initial layout validation.
4. Trigger Image Processing: The GPU process receives the frame and, depending on the hardware encoder requirements, invokes the LibYUVImageProcessorBackend for format conversion or scaling.
5. Out-of-Bounds Read: During processing, LibYUV uses the truncated negative stride to move between rows. Because pointers are 64-bit, adding the truncated signed int (effectively -2GB) causes LibYUV to read from memory locations 2GB and 4GB before the intended shared memory mapping.
6. Exfiltrate Data: The data read from these out-of-bounds locations is encoded into the output video bitstream and sent back to the renderer, allowing the attacker to recover privileged GPU process memory.

Impact

This issue provides a potential high-bandwidth memory disclosure primitive from the GPU process, which is unsandboxed on ChromeOS. This could be used to leak sensitive data or to assist in a multi-stage exploit to gain full control of the GPU process.

Suggested Fix

1. Update the FrameResource hierarchy and VideoFrameResource::stride() to return size_t instead of int to maintain consistency with media::VideoFrame.
2. Audit media/base/video_frame.cc to ensure that all stride-related arithmetic in GetVisibleDataInternal and other functions uses size_t or base::CheckedNumeric to prevent truncation and overflow.
3. Improve validation in Mojo traits to reject excessively large strides that are not practical for legitimate video frames but can be used to trigger arithmetic issues in downstream components.

Evaluated with Chrome root at commit: 29093e11cf509e3593f6229e4b1b075cca356049

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.