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.

Overview: The GLES2 validating decoder implements a workaround for Adreno GPUs that recreates multisampled renderbuffers during a resize. If the subsequent storage allocation fails due to GPU memory exhaustion, the decoder fails to invalidate its internal framebuffer completeness cache. This potentially allows a compromised renderer to bypass validation and dispatch draw commands against a malformed, zero-storage framebuffer, which may lead to memory corruption in the GPU process.

Affected files:

• gpu/command_buffer/service/renderbuffer_manager.cc
• gpu/command_buffer/service/gles2_cmd_decoder.cc
• gpu/command_buffer/service/framebuffer_manager.cc

Estimated timestamp from git blame: 2017-06-19

Vulnerability Details

The GLES2 validating command decoder implements a workaround (multisample_renderbuffer_resize_emulation) for Adreno 4xx and 5xx GPUs to handle driver bugs when resizing multisampled renderbuffers.

When a WebGL client resizes an existing MSAA renderbuffer via glRenderbufferStorageMultisample[CHROMIUM|EXT], the decoder triggers Renderbuffer::RegenerateAndBindBackingObjectIfNeeded in gpu/command_buffer/service/renderbuffer_manager.cc. This function:

1. Deletes the existing GL renderbuffer object.
2. Generates a new, unallocated GL renderbuffer (size 0).
3. Re-attaches this new object to all associated framebuffers using raw driver calls (glFramebufferRenderbufferEXT).
4. Sets allocated_ = false.

Crucially, this workaround helper does not reset the renderbuffer’s internal state (such as cleared_) and does not call UnmarkAsComplete() on the attached Framebuffer objects to invalidate their cached completeness state.

Following this, the decoder attempts to allocate the requested memory via the driver. If this allocation fails (e.g., throwing GL_OUT_OF_MEMORY), GLES2DecoderImpl::DoRenderbufferStorageMultisampleCHROMIUM detects the error and skips the call to renderbuffer_manager()->SetInfoAndInvalidate(...).

Because SetInfoAndInvalidate is bypassed, the decoder’s internal cache is completely desynchronized from the driver:

• The Framebuffer remains marked as complete in the FramebufferManager cache.
• The Renderbuffer remains marked as cleared_ = true.
• The underlying GL driver object is actually a zero-storage, unallocated attachment.

Subsequent commands like glDrawArrays or glBlitFramebuffer will pass GLES2DecoderImpl::CheckFramebufferValid because the stale cache returns true for IsComplete(), and the stale cleared_ flag bypasses ClearUnclearedAttachments. The validating decoder will pass the command directly to the Adreno driver with an invalid FBO, which can lead to undefined behavior or memory corruption in the GPU process.

Potential Attacker Steps

(Note: These are suggested steps based on static analysis; we do not have a working PoC yet.)

1. From a malicious web page, create a WebGL context ensuring lose_context_when_out_of_memory is set to false (which is the default). This ensures the context survives allocation failures.
2. Create a multisampled renderbuffer, attach it to a Framebuffer Object (FBO), and issue a glClear. This primes the decoder’s state, marking the FBO as complete and the attachment as cleared.
3. Intentionally exhaust available GPU memory (e.g., by allocating numerous maximum-size textures).
4. Attempt to resize the multisampled renderbuffer to a massive size. On an Adreno 4xx/5xx device, this triggers the multisample_renderbuffer_resize_emulation workaround, replacing the underlying GL object. The subsequent allocation will fail due to the OOM condition.
5. Issue a glDrawArrays or glBlitFramebuffer using the desynchronized FBO. The validating decoder will trust its stale cache and forward the command to the driver, potentially corrupting driver state or GPU process memory.

Suggested Fix

Ensure that the internal state is properly invalidated when the multisample_renderbuffer_resize_emulation workaround is triggered, regardless of whether the subsequent allocation succeeds or fails.

In gpu/command_buffer/service/renderbuffer_manager.cc inside Renderbuffer::RegenerateAndBindBackingObjectIfNeeded, explicitly reset the renderbuffer’s metadata and invalidate the framebuffers:

  allocated_ = false;
  cleared_ = false;
  width_ = 0;
  height_ = 0;
  samples_ = 0;
  
  // Invalidate all attached framebuffers
  for (auto& point : framebuffer_attachment_points_) {
    point.first->UnmarkAsComplete();
  }
  return true;

Alternatively, DoRenderbufferStorageMultisampleCHROMIUM (and the EXT variant) should ensure that if the workaround mutated the backing object, SetInfoAndInvalidate (or a similar invalidation path) is called to reset the state back to unallocated/uncleared even if a GL error occurred.

Evaluated with Chrome root at commit: 096fc8fdbfacf2546485756d03f160a3d04fcc9b

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.