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 compromised renderer can forge the size metadata of an ExportedSharedImage, which is trusted by the GPU process without validation against the underlying DXGI handle. This allows an attacker to pass an out-of-bounds source rectangle to D3D11 operations in the MediaFoundationVideoEncodeAccelerator. This can potentially result in an out-of-bounds read of adjacent GPU memory, which is encoded and leaked back to the renderer.

Affected files:

• media/gpu/windows/media_foundation_video_encode_accelerator_win.cc
• media/mojo/services/mojo_video_encode_accelerator_service.cc
• gpu/command_buffer/client/client_shared_image.cc
• gpu/command_buffer/client/internal/mappable_buffer_dxgi.cc
• media/base/video_frame.cc
• media/mojo/mojom/video_frame_mojom_traits.cc

Estimated timestamp from git blame: 2025-09-04

Description

A potential vulnerability exists in the Media Foundation Video Encode Accelerator (MFVEA) on Windows where a compromised renderer can cause an out-of-bounds (OOB) read of GPU memory. The issue occurs because the GPU process trusts the metadata.size of an ExportedSharedImage over IPC without verifying it against the actual dimensions of the underlying DXGI resource.

This unvalidated size bypasses encoder validation checks, allowing an oversized visible_rect to be used when building source regions for D3D11 scaling and copy operations. Because the D3D11 driver is instructed to read beyond the bounds of the actual allocation, it may access adjacent GPU memory.

Potential Attacker Steps

Although an end-to-end proof of concept has not been executed, tracing the code suggests the following sequence of events could trigger the vulnerability:

1. Resource Creation: A compromised renderer process creates a small, valid DXGI-backed SharedImage (e.g., 64x64 pixels) and obtains its underlying OS handle (gfx::GpuMemoryBufferHandle).
2. Metadata Forgery: The renderer constructs a malicious media::mojom::VideoFrame to send to the GPU process. In the ExportedSharedImage payload, it includes the valid OS handle but forges metadata.size, coded_size, and visible_rect to a much larger dimension (e.g., 8192x8192).
3. Missing Validation on Import: The GPU process deserializes the frame. In gpu/command_buffer/client/internal/mappable_buffer_dxgi.cc, CreateFromHandle wraps the DXGI handle without querying the OS to ensure the texture is actually as large as the provided size.
4. Encoder Check Bypass: The VideoFrame adopts the forged dimensions. When it reaches MojoVideoEncodeAcceleratorService::Encode, it bypasses the input_coded_size_ mismatch check because frame->HasMappableSharedImage() evaluates to true.
5. OOB D3D11 Operation: The frame reaches MediaFoundationVideoEncodeAccelerator.
   • In PerformD3DScaling, the code correctly queries the actual texture dimensions via input_texture->GetDesc(). However, it ignores these dimensions, blindly constructing a RECT source_rect using the attacker-controlled visible_rect.
   • This oversized source_rect is passed to VideoProcessorSetStreamSourceRect and executed via VideoProcessorBlt.
   • (Alternatively, the same flaw exists in PerformD3DCopy where an oversized D3D11_BOX src_box is passed to CopySubresourceRegion).
6. Information Leak: The D3D11 driver executes the OOB read. The leaked GPU memory is processed, encoded into a video bitstream by the Media Foundation hardware encoder, and the compressed payload is returned to the compromised renderer.

Impact

This vulnerability potentially allows a compromised renderer process to read arbitrary GPU memory from other origins or desktop applications, resulting in a cross-origin information leak (Sandbox Escape). Providing invalid, out-of-bounds regions to D3D11 drivers might also result in memory corruption within the unsandboxed GPU process or cause the user-mode driver to crash.

Recommended Fix

1. MFVEA Clamping: In media/gpu/windows/media_foundation_video_encode_accelerator_win.cc, update PerformD3DScaling and PerformD3DCopy to clamp the visible_rect to the actual dimensions of the texture (obtained via GetDesc()) before constructing source_rect and src_box.
2. Import Validation: Consider adding validation to MappableBufferDXGI::CreateFromHandle (similar to MappableBufferIOSurface) to query the underlying DXGI resource and reject the import if the requested size exceeds the actual resource bounds.

Evaluated with Chrome root at commit: eca8648a4e1cdfdda68c495a6003059fed641955

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. And please feel free to reach out to me directly if you have concerns or feedback on the project.