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: MediaFoundationVideoEncodeAccelerator::PerformD3DScaling lacks DXGI format validation on its input texture. A compromised renderer could potentially pass a texture with an unsupported format, causing the D3D11 Video Processor blit operation to silently fail on certain drivers while still returning S_OK. This allows the uninitialized VRAM of the scaled destination texture to be encoded and returned, potentially disclosing cross-origin GPU memory.

Affected files:

• media/gpu/windows/media_foundation_video_encode_accelerator_win.cc

Estimated timestamp from git blame: 2021-05-24

Description

There is a potential information disclosure vulnerability in the Windows GPU process implementation of the Media Foundation Video Encode Accelerator (MediaFoundationVideoEncodeAccelerator).

The function PerformD3DScaling in media/gpu/windows/media_foundation_video_encode_accelerator_win.cc processes renderer-supplied DXGI textures when input scaling is required. However, it lacks an explicit DXGI format verification check on the input texture. In contrast, its sibling function PerformD3DCopy explicitly validates that the input texture format is DXGI_FORMAT_NV12 before performing operations:

// media/gpu/windows/media_foundation_video_encode_accelerator_win.cc (PerformD3DCopy)
if (input_desc.Format != DXGI_FORMAT_NV12) {
  LOG(ERROR) << "Format mismatch: source format " << input_desc.Format
             << " is not DXGI_FORMAT_NV12";
  return E_INVALIDARG;
}

Without this check, PerformD3DScaling permits arbitrary DXGI formats. It sets up an ID3D11VideoProcessorInputView and calls ID3D11VideoContext::VideoProcessorBlt to scale the input texture into a newly allocated destination texture (scaled_d3d11_texture_). This destination texture is created without initial data (passing nullptr to CreateTexture2D), leaving its underlying GPU VRAM uninitialized.

According to Microsoft D3D11 documentation for ID3D11VideoProcessorEnumerator::CheckVideoProcessorFormat, an unsupported format may successfully pass view creation and even blit calls but fail to process correctly: > “A format that is not supported might still succeed the CreateVideoProcessorInputView or CreateVideoProcessorOutputView call, but the format might not work correctly when you call ID3D11VideoContext::VideoProcessorBlt.”

If a driver-level video processor silently drops the blit operation on an unsupported format but returns S_OK, the uninitialized GPU memory within the destination texture is preserved. This memory is then wrapped into an IMF media buffer, has its active length set to the maximum size, and is sent to the hardware video encoder MFT. The encoder compresses the uninitialized VRAM, and the resulting bitstream is returned back to the renderer, potentially leaking cross-origin GPU data.

Note: The steps described below are theoretical and suggested based on static code analysis; our analysis tooling does not currently have the capability to execute code or run dynamic proofs-of-concept.

Potential Attack Steps

1. From a compromised renderer, create a GPU SharedImage backed by a D3D11 texture with a bindable but VideoProcessor-unsupported DXGI format (e.g., DXGI_FORMAT_R32_FLOAT or DXGI_FORMAT_R16G16_UNORM).
2. Request a video encoding session via the media.mojom.VideoEncodeAccelerator interface, specifying PIXEL_FORMAT_NV12 as the input format.
3. Send an Encode IPC message containing the GpuMemoryBufferHandle of the unsupported format texture, but set the accompanying VideoFrame metadata format to PIXEL_FORMAT_NV12 to pass upstream format validation checks.
4. Ensure the VideoFrame’s visible_rect resolution differs from the initialized input size of the encoder to force the execution of PerformD3DScaling rather than PerformD3DCopy.
5. If the GPU driver’s video processor blit operation silently fails (returning S_OK without writing to the output view), the uninitialized destination texture will be encoded and returned to the renderer as compressed video frames.

Suggested Fix

Add an explicit DXGI format validation check at the beginning of MediaFoundationVideoEncodeAccelerator::PerformD3DScaling (or inside InitializeD3DVideoProcessing) to ensure that the input texture format matches the expected format (e.g., DXGI_FORMAT_NV12), mirroring the check present in PerformD3DCopy:

if (input_texture_desc.Format != DXGI_FORMAT_NV12) {
  LOG(ERROR) << "Format mismatch: scaling source format " << input_texture_desc.Format
             << " is not DXGI_FORMAT_NV12";
  return E_INVALIDARG;
}

Evaluated with Chrome root at commit: 84065d9121f6e48f67755f0ae963cc09617e5c85

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.