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 potential vulnerability in the Media Foundation Video Encode Accelerator (MFVEA) could allow a compromised renderer to leak GPU texture data from other origins. The issue stems from failing to ensure a GL context is current before performing operations that rely on thread-local GL state. This leads to cross-origin texture ID confusion when using the passthrough command decoder.

Affected files:

• media/base/win/mf_helpers.cc
• gpu/command_buffer/service/shared_image/d3d_image_representation.cc
• media/gpu/windows/media_foundation_video_encode_accelerator_win.cc

Estimated timestamp from git blame: 2025-01-28

Root Cause analysis

In media/base/win/mf_helpers.cc, the function media::GenerateResourceOnSyncTokenReleased() calls SharedImageManager::ProduceVideo() without first ensuring that a valid GL context is made current on the executing thread.

The callback for GenerateResourceOnSyncTokenReleased is scheduled on a dedicated GPU scheduler sequence (wait_sequence_id_) created by CommandBufferHelperImpl. This sequence executes on the GPU main thread but lacks associated GL context management. In Chrome’s GPU process, gl::g_current_gl_context is a thread_local variable. For performance, CommandBufferStub tasks leave the last used GL context current on the thread rather than clearing it upon completion. Consequently, when the MFVEA callback executes, it inherits whatever GL context was left bound by the previous task—likely a WebGL context belonging to a different renderer origin.

Potential execution Flow

When a mailbox resolves to a GLTextureImageBacking (which a compromised renderer can trigger by requesting GLES2_READ|WRITE usage), the following potential execution flow occurs:

1. SharedImageManager::ProduceVideo calls GLTextureImageBacking::ProduceVideo, which invokes D3D11VideoImageCopyRepresentation::CreateFromGL in gpu/command_buffer/service/shared_image/d3d_image_representation.cc.
2. CreateFromGL retrieves the stale thread_local GL context from gl::g_current_gl_context.
3. It then issues GL commands, including glCopySubTextureCHROMIUM(gl_texture_id, ...). Here, gl_texture_id is the service ID of the attacker’s SharedImage (allocated in the SharedContextState’s namespace).
4. Under the passthrough command decoder, every WebGL context and the SharedContextState have distinct GL share groups. Service ID N from the attacker’s namespace may refer to a completely different texture in the victim’s stale context.

Because ANGLE allocates texture IDs sequentially, achieving an ID collision is trivial. If a collision occurs, the victim’s texture contents are copied into a D3D destination texture, which is then encoded by the Media Foundation Video Encode Accelerator. The resulting bitstream is then returned to the attacker’s renderer.

If no collision occurs or the stale context is in an error state, the code may hit a release-fatal CHECK_EQ(glGetError(), GL_NO_ERROR) in d3d_image_representation.cc, resulting in a GPU process crash.

Impact

This constitutes a potential high-severity cross-origin information leak, allowing an attacker to read pixel data from GPU textures belonging to other origins. Alternatively, it can be used to cause a Denial of Service by crashing the GPU process.

Suggested Fix

The fix is to ensure the SharedContextState’s GL context is made current before calling ProduceVideo. This matches the implementation already present in the sibling D3D12 encoder (media/gpu/windows/d3d12_video_encode_accelerator.cc:149).

// Suggested change in media/base/win/mf_helpers.cc
if (!shared_image_stub->shared_context_state()->MakeCurrent(nullptr)) {
  RETURN_ON_FAILURE_WITH_CALLBACK(E_FAIL, "Failed to make context current");
}

Evaluated with Chrome root at commit: b3153093eb3c78c3e88ccf562bcbc20437a04b0e

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.