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 logic error in the Windows MFAudioEncoder class causes it to append new buffers to an output sample without removing old ones when output size requirements increase. This leads to the disclosure of uninitialized GPU process heap memory to the renderer process and eventual process exhaustion.

Affected files:

• media/gpu/windows/mf_audio_encoder.cc
• media/gpu/windows/mf_audio_encoder.h
• media/base/win/mf_helpers.cc

Estimated timestamp from git blame: 2022-03-08

Summary

A potential vulnerability exists in media/gpu/windows/mf_audio_encoder.cc where incorrect management of IMFSample buffers can lead to an out-of-bounds read of uninitialized GPU process memory and an unbounded memory leak (Denial of Service). This occurs when the Media Foundation Transform (MFT) requires a larger output buffer than the one currently allocated.

Technical Analysis

In media/gpu/windows/mf_audio_encoder.cc, the helper function GetSampleBuffer manages a persistent IMFSample (stored in output_sample_) used to receive data from the Media Foundation encoder.

When the required output size (required_size) exceeds the capacity of the current buffer, the code allocates a new buffer. However, it fails to remove the existing buffer from the sample, instead appending the new one:

// media/gpu/windows/mf_audio_encoder.cc:334
if (need_buffer_allocation) {
  RETURN_IF_FAILED(
      MFCreateAlignedMemoryBuffer(required_size, buffer_alignment, &buffer));
  RETURN_IF_FAILED(sample->AddBuffer(buffer.Get())); // Potential logic error: Appends instead of replacing
}

This creates a multi-buffer sample. In MFAudioEncoder::ProcessOutput, the code calculates the total length of data written across all buffers in the sample using GetTotalLength(), but then copies that total amount from only the most recently added buffer (output_buffer):

// media/gpu/windows/mf_audio_encoder.cc:899
DWORD total_length;
RETURN_IF_FAILED(output_sample_->GetTotalLength(&total_length));

// output_buffer refers only to the last-added buffer
MediaBufferScopedPointer locked_output_buffer(output_buffer.Get());
auto encoded_data = base::HeapArray<uint8_t>::CopiedFrom(
    locked_output_buffer.as_span().first(total_length)); // Out-of-bounds read

Because Media Foundation MFTs fill buffers in the sample sequentially, the first (smaller) buffer is filled first. If the MFT writes 5000 bytes and Buffer 0 has a capacity of 4096, only 904 bytes are written to Buffer 1. The code then attempts to copy 5000 bytes from the start of Buffer 1, resulting in the disclosure of ~4000 bytes of uninitialized GPU process heap memory to the renderer.

Furthermore, because the code always checks the capacity of the buffer at index 0 (sample->GetBufferByIndex(0, &buffer)), and that buffer is never replaced, every subsequent call will trigger a new allocation and append, leading to unbounded memory growth and a deterministic crash when total_length exceeds the capacity of the latest buffer.

Suggested Potential Steps to Reproduce

1. Use a compromised renderer to initialize a media.mojom.AudioEncoder on Windows using AAC.
2. Enable Variable Bit Rate (VBR) mode or trigger a condition that causes the MFT to increase its cbSize requirement via GetOutputStreamInfo.
3. Send audio frames for encoding.
4. Observe the returned EncodedAudioBuffer data. If the vulnerability is present, the buffer will contain segments of uninitialized memory from the GPU process heap.
5. Continue sending frames to observe a steady increase in GPU process memory usage until a crash occurs.

Recommended Fix

In media/gpu/windows/mf_audio_encoder.cc, the GetSampleBuffer function should call sample->RemoveAllBuffers() before calling sample->AddBuffer(buffer.Get()) when a new buffer allocation is required. This ensures the IMFSample always contains exactly one buffer of sufficient size.

Evaluated with Chrome root at commit: 1a8d40fc44df2088d5945c0bf53584038aa1614a

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.