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 security team.

Overview: In Chrome’s GPU service, DawnEGLImageRepresentation::BeginAccess ignores the return value of its underlying GL representation access call. This allows a compromised renderer to bypass GPU synchronization and clear-state tracking by mapping the same SharedImage mailbox to multiple WebGPU textures concurrently. As a result, an attacker can potentially trigger a GPU-side data race to read uninitialized memory or cross-origin texture residue on older Android devices.

Affected files:

• gpu/command_buffer/service/shared_image/dawn_egl_image_representation.cc
• gpu/command_buffer/service/webgpu_decoder_impl.cc
• gpu/command_buffer/service/shared_image/shared_image_representation.h

Estimated timestamp from git blame: 2024-06-03

Background

On Android devices lacking Vulkan support, Chrome’s WebGPU implementation falls back to OpenGLES. In this path, DawnEGLImageRepresentation is used to wrap EGLImage-backed SharedImages so they can be accessed by Dawn. Proper synchronization between Dawn and other GL contexts relies on acquiring exclusive read/write access to the SharedImage backing and emitting GL fences.

The Vulnerability

In gpu/command_buffer/service/shared_image/dawn_egl_image_representation.cc:67, the boolean return value of gl_representation_->BeginAccess(...) is ignored:

64: wgpu::Texture DawnEGLImageRepresentation::BeginAccess(...) {
65:   gl_representation_->BeginAccess(ToSharedImageAccessGLMode(usage)); // Return value ignored
66:   // ... proceeds to successfully wrap the EGLImage and return a wgpu::Texture ...
67: }

If the SharedImage is already locked by another writer, gl_representation_->BeginAccess() safely returns false, and its internal state mode_ remains kNone. However, because DawnEGLImageRepresentation ignores this failure, it proceeds to hand Dawn a valid wgpu::Texture handle for a texture it does not exclusively own.

Potential Exploit Steps

Note: These are suggested/potential steps derived from code analysis; our tooling agent does not run code to produce a live proof-of-concept.

An attacker in a compromised renderer could trigger a GPU data race using the following sequence:

1. Create SharedImage: The attacker creates an uninitialized SharedImage via GPU IPC.
2. Associate ID 1: The attacker sends an AssociateMailboxImmediate command to the WebGPU decoder, associating the mailbox with a WebGPU texture id=1 and requesting WEBGPU_WRITE usage. This successfully acquires the write lock on the EGLImageBacking.
3. Associate ID 2: The attacker associates the same mailbox with a second WebGPU texture id=2. WebGPUDecoderImpl permits multiple IDs for the same mailbox. Because id=1 holds the lock, BeginWrite() fails, but the failure is ignored. id=2 successfully wraps the texture, but its internal access mode_ remains kNone.
4. Generate Stale Fence: The attacker dissociates id=1. The EndAccess call drops the write lock and generates a new write_fence_ (e.g., GLFenceEGL), representing the GPU state before any commands for id=2 are submitted.
5. Submit Unfenced Work: The attacker uses id=2 to submit a lazy-clear or compute operation in Dawn. These GL commands execute asynchronously on the GPU.
6. Bypass New Fence Generation: The attacker dissociates id=2. Dawn marks the backing as fully initialized (SetCleared()). However, when gl_representation_->EndAccess() is called, it early-returns because mode_ is kNone. Crucially, no new write_fence_ is generated to synchronize the Dawn commands from step 5.
7. Race Condition and Data Leak: The attacker immediately reads the same SharedImage from a WebGL context. WebGL sees the texture is marked as cleared and skips its own security lazy-clear. It waits on the backing’s write_fence_, but this is the stale fence from step 4, which is already signaled. WebGL reads the memory immediately, racing with the asynchronous clear from step 5.

This race allows the attacker to read uninitialized GPU memory or cross-origin texture residue.

Suggested Fix

Check the return value of gl_representation_->BeginAccess(...) inside DawnEGLImageRepresentation::BeginAccess. If it returns false, fail gracefully by returning a null wgpu::Texture or an error texture, preventing Dawn from accessing a backing it failed to lock:

wgpu::Texture DawnEGLImageRepresentation::BeginAccess(
    wgpu::TextureUsage usage,
    wgpu::TextureUsage internal_usage) {
  if (!gl_representation_->BeginAccess(ToSharedImageAccessGLMode(usage))) {
    return nullptr;
  }
  // ...
}

Evaluated with Chrome root at commit: ff3d2b74fa39431785bd60e51463b08fcc71ee33

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.