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: A potential state desynchronization issue in WgcCaptureSession::ProcessFrame can lead to an out-of-bounds read of mapped Direct3D 11 staging memory. If a resize occurs and recreating the frame pool fails, the staging texture is left resized to a smaller dimension while the tracking state retains the old larger size. Subsequent frame processing at the original size bypasses reallocation and reads past the boundaries of the mapped texture.

Affected files:

• third_party/webrtc/modules/desktop_capture/win/wgc_capture_session.cc

Estimated timestamp from git blame: 2022-03-09

Summary of Root Cause

In WgcCaptureSession::ProcessFrame (located in third_party/webrtc/modules/desktop_capture/win/wgc_capture_session.cc), the capture session’s size-tracking member size_ is synchronized non-atomically when a captured window size changes.

When a resize to a smaller size is detected in ProcessFrame:

1. CreateMappedTexture is invoked (line 592), which successfully reallocates mapped_texture_ to the new smaller size (e.g., $A imes A$).
2. frame_pool_->Recreate is then called (line 598). If this allocation fails (for example, due to transient GPU memory pressure), the function returns early on line 602.
3. Because of the early return, the session’s overall size-tracking variable size_ is not updated to the new size and remains at the old larger size (e.g., $S imes S$).

If the captured window is then resized back to the larger size $S$:

1. SizeHasChanged(S, S) evaluates to false because both the incoming frame size and the stale tracking member size_ are $S$. The resize block is completely bypassed.
2. The copy dimensions image_height and image_width are computed as min(size_, new_size) = S (lines 615-616).
3. The code maps mapped_texture_ (which is still sized $A imes A$) and enters a loop copying $S$ rows of $S imes 4$ bytes using memcpy (lines 719-730).
4. In production builds, RTC_DCHECK_GE checks are disabled. This results in an out-of-bounds memory read from the mapped staging texture buffer.

Potential Steps to Trigger

Note: These are suggested/potential steps modeled from static analysis; our tooling agent does not currently have the capability to run code or compile a working proof-of-concept.

1. A web page requests screen or window capture using getDisplayMedia, and the user selects a window of size $S$ (e.g., $1000 \times 1000$).
2. The attacker triggers transient GPU memory pressure (e.g., by spawning multiple heavy WebGL/WebGPU contexts or massive resource allocations) to prepare for an allocation failure.
3. The captured window is resized to a smaller dimension $A$ (e.g., $500 \times 500$).
4. ProcessFrame enters the resize block, reallocates mapped_texture_ to $A$, but fails to recreate the frame pool due to GPU memory pressure, returning early.
5. The captured window is resized back to the larger size $S$.
6. On the next frame capture, the code bypasses resizing because size_ was never updated from $S$. It attempts to copy a larger frame region out of the smaller staging texture, resulting in an out-of-bounds read of adjacent mapped memory in the browser process.

Suggested Fix

Ensure that if any part of the resizing sequence fails, the session either rolls back the staging texture, marks the session as permanently failed, or updates size_ defensively. For instance, in wgc_capture_session.cc:

    hr = frame_pool_->Recreate(direct3d_device_.Get(), kPixelFormat,
                               num_buffers(), new_size);
    if (FAILED(hr)) {
      RecordGetFrameResult(GetFrameResult::kRecreateFramePoolFailed);
      // Ensure the session size is synchronized or invalidated on failure
      size_ = new_size; 
      return hr;
    }

Evaluated with Chrome root at commit: 5133b93d189b383c37805b1cf3a9d2dbfe8d7379

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.