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: RasterDecoderImpl::DoWritePixelsINTERNALDirectTextureUpload returns record-time success for Graphite texture uploads while ignoring insert-time recording failures in SharedContextState::FlushGraphiteRecorder. This can allow a compromised renderer to prematurely mark a SharedImage as cleared, bypassing the uninitialized texture gate and reading back uninitialized GPU memory. The issue potentially allows cross-origin pixel disclosure from a singleton shared GPU process.

Affected files:

• gpu/command_buffer/service/raster_decoder.cc
• gpu/command_buffer/service/shared_context_state.cc

Estimated timestamp from git blame: 2023-05-12

Root Cause Analysis

In Chromium’s GPU service, RasterDecoderImpl::DoWritePixelsINTERNALDirectTextureUpload handles direct texture uploads when using the Skia Graphite backend. However, it returns a boolean based purely on the record-time result, while the actual command execution/insertion is handled via a void helper that discards the result.

Specifically, in gpu/command_buffer/service/raster_decoder.cc:

  } else {
    CHECK(graphite_shared_context());
    ...
    written = graphite_recorder()->updateBackendTexture(
        graphite_texture_ptr->texture(), &pixmap,
        /*numLevels=*/1, release_proc, graphite_texture_ptr);
  }

  shared_context_state_->FlushWriteAccess(dest_scoped_access.get());
  shared_context_state_->SubmitIfNecessary(
      std::move(end_semaphores),
      dest_scoped_access->NeedGraphiteContextSubmit());

  return written;

Here, written receives the return value of updateBackendTexture, which only enqueues an UploadTask into Skia Graphite’s recorder. This returns true at record time before any commands are inserted or executed.

Immediately after, FlushWriteAccess is called, which cascades into SharedContextState::FlushGraphiteRecorder() in gpu/command_buffer/service/shared_context_state.cc:

void SharedContextState::FlushGraphiteRecorder() {
  auto recording = gpu_main_graphite_recorder()->snap();
  if (recording) {
    skgpu::graphite::InsertRecordingInfo info = {};
    info.fRecording = recording.get();
    graphite_shared_context()->insertRecording(info);    // <--- Boolean return value is ignored!
  }
}

If the recording fails to insert (for instance, returning skgpu::graphite::InsertStatus::kAddCommandsFailed due to transient setup failures or allocator issues), the failure is silently discarded. No context loss is triggered because kAddCommandsFailed is categorized as a recoverable error in GraphiteSharedContext::InsertRecordingImpl.

Impact on Clear-State Tracking

Because DoWritePixelsINTERNALDirectTextureUpload returns true (the record-time success status), the caller in RasterDecoderImpl::DoWritePixelsINTERNAL prematurely marks the SharedImage as fully cleared:

    if (!dest_shared_image->IsCleared()) {
      dest_shared_image->SetClearedRect(
          gfx::Rect(src_info.width(), src_info.height()));
    }

Once marked cleared, subsequent readback requests (such as ReadbackARGBImagePixelsINTERNALImmediate) bypass the uninitialized texture gate in SkiaGraphiteImageRepresentation::BeginScopedReadAccess:

  if (!IsCleared()) {
    ...
    return nullptr; // Blocks uninitialized read
  }

Furthermore, the IsCleared() status is passed to Dawn/Vulkan during readback as begin_access_desc.initialized = true, which commands Dawn to skip lazy zero-clearing of the texture. As a result, uninitialized physical GPU memory (containing residue from previously allocated/freed textures across different origins) is read directly into the renderer-owned shared memory buffer.

Suggested Potential Trigger Steps

Note: These are suggested potential steps only; our tooling currently lacks the ability to execute code and verify this sequence dynamically.

1. A compromised renderer allocates an uncleared single-plane SharedImage (e.g., viz::SinglePlaneFormat::kBGRA_8888) with SHARED_IMAGE_USAGE_RASTER_READ | RASTER_WRITE | DISPLAY_READ flags and no initial pixels.
2. The renderer induces transient GPU device pressure (e.g., allocating large buffers or textures via WebGPU) to make subsequent command allocations/command buffer setup fail.
3. The renderer calls WritePixelsINTERNALImmediate targeting the SharedImage, using dimensions matching the SharedImage’s size to trigger the direct upload fast-path.
4. Inside the GPU process, updateBackendTexture returns true at record-time, but insertRecording returns false due to kAddCommandsFailed. This failure is ignored.
5. The GPU process calls SetClearedRect, marking the uninitialized texture as cleared.
6. The renderer calls ReadbackARGBImagePixelsINTERNALImmediate on the mailbox. The IsCleared() check is bypassed, and the GPU copies cross-origin texture residues into the renderer’s shared memory.

Suggested Fix

To prevent uninitialized memory disclosure, the GPU process must ensure that clear-state updates only happen if the command insertion succeeds.

We suggest updating DoWritePixelsINTERNAL and DoWritePixelsINTERNALDirectTextureUpload to propagate the actual insert status, or ensuring FlushWriteAccess can return a status indicating whether the recording was successfully inserted. If the insert fails, the SharedImage must not be marked cleared.

Evaluated with Chrome root at commit: b5b015ea5f690560237d1f0cff1405844cd12b8d

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.