Flapjack, 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 go/chrome-ai-generated-security-bugs-faq for more information.

Overview: The GPU process’s validating command buffer contains a double-fetch vulnerability when processing buffer updates like glBufferSubData. It reads from client-controlled shared memory twice: once to update a CPU-side shadow buffer used for validation, and again to send data to the GL driver. A compromised renderer can concurrently modify this shared memory to bypass index bounds validation, potentially causing an out-of-bounds access in the GPU hardware.

Affected files:

• gpu/command_buffer/service/buffer_manager.cc
• gpu/command_buffer/service/gles2_cmd_decoder.cc

Estimated timestamp from git blame: 2025-11-28

Vulnerability Details

To prevent malicious WebGL content from causing out-of-bounds (OOB) memory accesses in the GPU driver, the validating command buffer maintains a CPU-side “shadow” copy of GL_ELEMENT_ARRAY_BUFFER (index buffer) data. During a glDrawElements call, the service scans this shadow buffer to find the maximum index accessed, ensuring it fits within the bounds of the currently bound vertex attributes.

However, several buffer update functions exhibit a time-of-check to time-of-use (TOCTOU) / double-fetch vulnerability when reading from shared memory. For example, in BufferManager::DoBufferSubData:

void BufferManager::DoBufferSubData(
    Buffer* buffer, GLenum target, GLintptr offset, GLsizeiptr size,
    const GLvoid* data) {
  // FETCH 1: Copies data from shared memory `data` to the CPU shadow buffer
  buffer->SetRange(offset, size, data);

  if (!buffer->IsClientSideArray()) {
    // FETCH 2: Driver reads directly from the shared memory `data` to GPU memory
    glBufferSubData(target, offset, size, data);
  }
}

The data pointer originates from a transfer buffer (base::UnsafeSharedMemoryRegion) mapped by both the renderer and the GPU process. Because there are no cross-process locks, the renderer can modify the memory between SetRange and glBufferSubData. Similar vulnerable patterns exist in GLES2DecoderImpl::DoFlushMappedBufferRange and GLES2DecoderImpl::UnmapBufferHelper.

Potential Exploitation Steps

(Note: These are suggested/potential steps, as our tooling agent does not have the ability to run code or verify a live Proof of Concept.)

1. Renderer Compromise: An attacker gains code execution in a sandboxed renderer process.
2. Setup: The attacker initializes a WebGL context, creating a small vertex buffer and an element array buffer.
3. Race Preparation: The attacker maps a shared memory transfer buffer and issues a BufferSubData command pointing to it.
4. Concurrent Modification: A worker thread in the renderer rapidly alternates the contents of the shared memory between “safe” indices (within vertex buffer bounds) and “malicious” indices (large, out-of-bounds values).
5. Winning the Race: If the GPU process executes buffer->SetRange while the memory contains safe indices, the shadow buffer is populated safely. Microseconds later, the renderer thread overwrites the shared memory with malicious indices. The GPU process then executes glBufferSubData, uploading the malicious indices to GPU VRAM.
6. Triggering the OOB: The attacker issues a glDrawElements command. The GPU service validates the draw call using the safe indices in the shadow buffer, allowing the call to proceed. The underlying GPU hardware executes the draw using the malicious VRAM buffer, resulting in an OOB memory access.

Because the validating command decoder is the default on Android, and the GPU process is unsandboxed on that platform, an OOB access in the GPU driver can potentially lead to a full sandbox escape.

Suggested Fix

Do not pass the raw shared memory pointer to the underlying GL driver if the buffer is shadowed. Instead, copy the data once into service-side memory (which the SetRange call already does by populating shadow_), and pass the safe, service-side pointer to the GL driver.

For example, in BufferManager::DoBufferSubData:

  buffer->SetRange(offset, size, data);
  if (!buffer->IsClientSideArray()) {
    // Pass the pointer from the shadow buffer, not the shared memory
    glBufferSubData(target, offset, size, buffer->GetRange(offset, size));
  }

Similar refactoring should be applied to DoFlushMappedBufferRange and UnmapBufferHelper to ensure that data written to the GPU strictly matches the data validated in the shadow buffer.

Evaluated with Chrome root at commit: c0eb5541aebfa4ea08806eaf6e94bcc69f87ab2f

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.