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: An integer wrap-around vulnerability exists in CompoundImageBacking where latest_content_id_ can overflow to 0 via repeated IPC updates. This wrapped value collides with the default sentinel of an uninitialized GPU backing, bypassing synchronization checks. Consequently, a compromised renderer can read recycled, uninitialized GPU memory, potentially leaking cross-origin graphics data.

Affected files:

• gpu/command_buffer/service/shared_image/compound_image_backing.cc
• gpu/command_buffer/service/shared_image/compound_image_backing.h

Estimated timestamp from git blame: Unknown (Google3 checkout)

1. Summary of the Issue (Meant for Human Triage)

A potential integer wrap-around vulnerability exists in CompoundImageBacking within Chromium’s GPU command buffer service. The class tracks the latest version of content across multiple underlying backings (such as Shared Memory and GPU) using latest_content_id_, a 32-bit unsigned integer. This ID is incremented with an unchecked bare ++ operator every time the shared image is updated. If a compromised renderer sends 2^32 - 1 updates to a single mailbox, the ID overflows and wraps back to 0.

This wrapped value of 0 perfectly collides with the default 0 content ID sentinel on never-synchronized elements, such as lazily allocated GPU backings. On the subsequent first GPU access, the collision (0 == 0) mistakenly satisfies the fast-path condition in NotifyBeginAccess. This causes the GPU process to skip the necessary synchronization copy (CopyImage) from the shared memory backing to the GPU texture. Since the GPU backing was already marked as cleared during creation (SetCleared()) on the assumption that a copy would occur on first access, all downstream validation gates (like IsCleared()) pass. Consequently, the renderer can perform an uninitialized GPU texture read. On platforms or drivers where the GPU allocator recycles graphics memory without zeroing (and where robust_resource_init is disabled on the shared context), this leaks recycled GPU graphics allocations, potentially exposing cross-origin graphic contexts from other tabs or processes.

2. Proof-of-Concept & Detailed Execution Flow

The following is a step-by-step theoretical sequence of events tracing the vulnerability from an attacker-controlled renderer to the uninitialized GPU memory read. Note that these are potential steps, as our tooling does not yet have the ability to run code to produce a live proof of concept.

Phase 1: Initialization and Setup

1. Attacker Connection: A compromised renderer process establishes a Mojo connection to the GPU process via gpu.mojom.GpuChannel.
2. Creation Request: The attacker sends a DeferredSharedImageRequest::kCreateSharedImageWithBuffer Mojo message, specifying a SHARED_MEMORY_BUFFER and usage flags GLES2_READ | CPU_WRITE_ONLY.
3. Factory Allocation: The GPU process routes the request to SharedImageFactory::CreateSharedImage. Because gmb_type == gfx::SHARED_MEMORY_BUFFER and it is not thread-shared, it calls CompoundImageBacking::Create (gpu/command_buffer/service/shared_image/compound_image_backing.cc:965).
4. Global Tracker Initialized: In the CompoundImageBacking constructor, latest_content_id_ (a uint32_t) is initialized to 1 by its default member initializer (compound_image_backing.h:463).
5. Shared Memory Element Setup: The constructor provisions elements_[0] to hold the Shared Memory backing and synchronizes its version: shm_element.content_id_ = latest_content_id_; (setting it to 1) (compound_image_backing.cc:1150).
6. Logical Clearing: Because a Shared Memory backing is present (has_shm_backing_ = true), the entire compound backing is marked logically cleared via SetClearedRectInternal(gfx::Rect(size)) (compound_image_backing.cc:1157).
7. Lazy GPU Element Setup: A placeholder element, elements_[1], is added for the eventual GPU backing. Its physical creation is deferred using LazyCreateBacking (compound_image_backing.cc:1167).
8. Sentinel Left Untouched: Crucially, gpu_element.content_id_ is not explicitly set in the constructor. It retains its default initializer value of 0 (compound_image_backing.h:337).
   • State Checkpoint 1: latest_content_id_ == 1, elements_[0].content_id_ == 1, elements_[1].content_id_ == 0.

Phase 2: Bypassing Watchdogs and Mojo Constraints

9. Mojo Batching Strategy: The maximum size of a single Mojo message is 128 MB (IPC::mojom::kChannelMaximumMessageSize). A single FlushDeferredRequests batch can hold a maximum of ~986,894 DeferredSharedImageRequests.
10. Watchdog Bypass: The attacker sends these 128 MB batches sequentially. When a batch reaches the GPU IO thread, GpuChannelMessageFilter::FlushDeferredRequests unpacks the items into individual Scheduler::Task elements without blocking Mojo queues. As the GPU Scheduler executes each task, the GpuWatchdogThread’s hooks continuously toggle arm_disarm_counter_, recognizing progress and preventing a timeout crash, permitting roughly 7 to 70 minutes of silent execution.
11. Service-Side Check Bypass: To prevent the GPU process from crashing when the client’s flush ID wraps around, the attacker hardcodes flushed_deferred_message_id = 1 in all IPC messages. This cleanly satisfies CHECK_GE(version, GetSharedVersion()) in SharedMemoryVersionController::SetVersion indefinitely.

Phase 3: Triggering the Wrap-Around

12. The IPC Loop: The attacker executes a loop sending batches of mojom::DeferredSharedImageRequest::kUpdateSharedImage aimed at the single shared image mailbox.
13. Updating the Compound Image: The GPU process routes these updates to CompoundImageBacking::Update() (compound_image_backing.cc:1415).
14. No-Op Child Update: Inside Update(), element.backing->Update() resolves to SharedMemoryImageBacking::Update, which is a CHECK(!in_fence); no-op that takes virtually no GPU cycles (shared_memory_image_backing.cc:104).
15. Unchecked Increment: Update() performs the unchecked increment:

  element.content_id_ = ++latest_content_id_;

16. The Overflow: At an estimated speed of tens of nanoseconds per increment, executing 4.3 billion tasks on the GPU main thread takes approximately 7 to 70 minutes. Upon executing the 4,294,967,295th update request, latest_content_id_ wraps around to 0 due to 32-bit unsigned integer overflow.
17. Final State Update: elements_[0].content_id_ is updated to the new latest_content_id_ value (0). elements_[1] was never accessed, so its content_id_ remains untouched at 0.

• State Checkpoint 2: latest_content_id_ == 0, elements_[0].content_id_ == 0, elements_[1].content_id_ == 0.

Phase 4: Lazy Allocation and Bypassing Synchronization

18. Forcing GPU Allocation: The attacker issues a GL command buffer command, CreateAndTexStorage2DSharedImageINTERNALImmediate, invoking ProduceGLTexturePassthrough, which enters CompoundImageBacking::GetOrAllocateBacking(SharedImageAccessStream::kGL).
19. Physical Allocation: elements_[1] matches the kGL access stream, firing its lazy callback to CreateBackingFromBackingFactory which allocates the physical backing texture (compound_image_backing.cc:2071).
20. Premature Clearing: The code notes if (has_shm_backing_) { backing->SetCleared(); }. It explicitly marks the physical texture as cleared—despite the driver returning raw, uninitialized memory—under the firm assumption that a synchronization copy from the Shared Memory backing will initialize it upon first access.
21. Initiating Access: The attacker sends BeginSharedImageAccessDirectCHROMIUM with read access (GL_SHARED_IMAGE_ACCESS_MODE_READ_CHROMIUM).
22. Clear Checks Defeated: BeginScopedAccess queries IsCleared(). Because of Step 20, this check passes seamlessly, bypassing EnsureClear (gles2_cmd_decoder_passthrough.cc:618).
23. The Collision: CompoundImageBacking::NotifyBeginAccess evaluates the critical fast-path condition:

  if (access_element && access_element->content_id_ == latest_content_id_) {

24. The Bypass: access_element points to elements_[1], whose content_id_ is 0. Due to the wrap-around, latest_content_id_ is also exactly 0. The condition evaluates to 0 == 0, which is true.
25. Skipping the Copy: Because the fast path returns true immediately (compound_image_backing.cc:1252), the system skips the copy_manager_->CopyImage invocation. The backing is now permanently bound without initialization.

Phase 5: Cross-Origin Data Leak

26. Reading the Texture: The attacker executes glReadPixels or samples the texture via a fragment shader to an SSBO using standard GLES2 commands.
27. Uninitialized Memory: By default, the shared context state operates with robust_resource_init = false (gles2_cmd_decoder_passthrough.cc:615). Thus, the underlying graphics driver (ANGLE-Vulkan or native GL) provides recycled, uninitialized GPU memory.
28. Impact: The attacker extracts the contents of the recycled GPU memory, leaking cross-origin graphics data from other origins, tabs, or background applications.

Proposed Fix

To prevent this vulnerability, latest_content_id_ should be protected against overflow. Given that uint32_t is used for content versions, base::CheckedNumeric<uint32_t> should be used to catch overflows and safely crash or handle the error, preventing wrap-around. Alternatively, use a 64-bit integer (uint64_t) for latest_content_id_ and content_id_, making an overflow impossible in a realistic timeframe.

3. Technical Verification Details (Automated Audit Logs - Reviewers may skip this section)

> Determination: verified — §G0.6/GPU-INT → GPU-XO. latest_content_id_ (uint32_t, .h:461) is incremented with bare ++ at .cc:1201,1268,1379 with no CheckedNumeric/overflow guard. After 2³²−1 A-RENDERER UpdateSharedImage IPCs it wraps to 0, colliding with the default elements_[1].content_id_ = 0 (.h:336, never assigned in ctor :1112-1123). The collision defeats NotifyBeginAccess:1198 (access_element->content_id_ == latest_content_id_ → 0==0 → fast-path return at :1204), so copy_manager_->CopyImage at :1217 is never invoked. The lazily-created GPU backing was already SetCleared() at :2031 without physical init (per the code’s own comment at :2023-2029), so both EnsureClear (gles2_cmd_decoder_passthrough.cc:618) and BeginScopedAccess (shared_image_representation.cc:152) IsCleared() gates pass → uninitialized GPU-texture read via readPixels.

Additional Verification Notes

• OOM / Watchdog Limits Verified: The prior Critic assessed whether 4.3 billion IPCs would crash the GPU process due to OOM or watchdog timeouts. It was confirmed that since Mojo requests are dispatched to the Scheduler and executed sequentially via RunNextTask (returning to the message loop), GpuWatchdogThread’s WillProcessTask/DidProcessTask observer hooks correctly arm and disarm the watchdog. By batching requests into 128 MB chunks (IPC::mojom::kChannelMaximumMessageSize), the Mojo queues do not pile up, completely avoiding OOMs.
• SharedMemoryVersionController Bypass: Sending 4.3 billion requests causes next_deferred_message_id_ to wrap around. The attacker can bypass the GPU process crash (CHECK_GE(version, GetSharedVersion()) in SharedMemoryVersionController::SetVersion, mojo/public/cpp/base/shared_memory_version.cc:92) by passing a static flushed_deferred_message_id (e.g., 1) repeatedly, as this check merely evaluates CHECK_GE(1, 1) unconditionally.
• Execution Timing: The lightweight SharedMemoryImageBacking::Update performs a negligible CHECK(!in_fence) operation. The entire update step (CompoundImageBacking::Update()) takes tens of nanoseconds. The estimated processing time for $2^{32}$ tasks on the GPU thread is between 7 and 70 minutes.
• Severity Alignment: The prior Critic classified this as Medium (S2) due to “extreme trigger complexity” (7-70 minutes). However, an automated, silent integer overflow triggered by a background tab loop does not require “unusual or unlikely user interaction,” and under Chromium’s threat model, automated background tasks scale effectively. Although the previous Critic assigned S2, the foundational cross-origin uninitialized-texture read (GPU-XO) boundary holds firm.

Evaluated with Chrome root at commit: b96d2ec58f4f5f92b540a723966b199d6e9951b4

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.