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 security team.

Overview: An attacker can potentially leak cross-origin WebGL texture data or uninitialized GPU heap memory on Windows via the ANGLE D3D11 backend. By calling glCopyTexSubImage2D with out-of-bounds coordinates, a shared scratch buffer is left unmodified during a read operation but is still copied into an attacker-controlled texture. This allows the attacker to read stale data originating from other contexts.

Affected files:

• third_party/angle/src/libANGLE/renderer/d3d/d3d11/Image11.cpp
• third_party/angle/src/libANGLE/renderer/d3d/d3d11/Renderer11.cpp

Estimated timestamp from git blame: 2022-10-19

Description

A potential information leak exists in the ANGLE D3D11 backend during WebGL texture copy operations.

When glCopyTexSubImage2D is called and format conversion is required, Image11::copyFromFramebuffer (in third_party/angle/src/libANGLE/renderer/d3d/d3d11/Image11.cpp) retrieves a shared scratch buffer (Renderer11::mScratchMemoryBuffer) to temporarily hold the intermediate pixel data. It then calls Renderer11::readFromAttachment to populate this buffer from the source framebuffer.

If an attacker provides source coordinates (x, y) that are entirely out-of-bounds of the source framebuffer, readFromAttachment mathematically clamps the read region to zero dimensions. Because the read dimensions are zero, the function immediately returns angle::Result::Continue without modifying the output scratch buffer.

Image11::copyFromFramebuffer receives the Continue result and blindly proceeds to execute the pixel conversion loadFunction, assuming the read populated the buffer. The conversion function reads width * height pixels from the unmodified scratch buffer and writes them into the attacker’s destination texture.

Since the scratch buffer is shared across all WebGL contexts on the D3D11 device and uses malloc without zero-initialization upon resizing, this flaw copies either uninitialized GPU heap memory or stale cross-origin texture data (from recent conversions) into the attacker’s texture.

Potential Trigger Steps

Note: These are suggested steps to trigger the vulnerability based on static code analysis. Our tooling cannot currently execute code to verify the PoC.

1. The attacker creates a WebGL context on a system using the D3D11 backend (default on Windows).
2. A victim origin performs WebGL operations that populate the shared Renderer11::mScratchMemoryBuffer with sensitive texture data.
3. The attacker creates a destination texture with a format that forces software conversion (e.g., GL_RGBA8).
4. The attacker creates a source framebuffer and attaches a texture with a format that cannot be directly copied via hardware (e.g., GL_LUMINANCE). This ensures the fallback conversion path in Image11::copyFromFramebuffer is triggered.
5. The attacker calls gl.copyTexSubImage2D(gl.TEXTURE_2D, 0, 0, 0, x, y, width, height) with x and y coordinates that are completely outside the source framebuffer’s actual dimensions.
6. The attacker reads back the destination texture using gl.readPixels or by drawing it to an HTML canvas, extracting the leaked cross-origin data or uninitialized heap memory.

Suggested Fix

There are a few ways to resolve this issue to conform to OpenGL semantics (which require out-of-bounds reads to return zeroed pixels) and prevent memory leaks:

1. Validate and Zero-fill Read Dimensions: In Image11::copyFromFramebuffer, determine the actual valid region that was read from the framebuffer. If the requested area is out-of-bounds, the scratch buffer (or the out-of-bounds regions of the destination texture) should be explicitly zero-filled before or after the loadFunction executes.
2. Explicitly handle Zero-Dimension Reads: If readFromAttachment calculates a safeArea of 0, Image11::copyFromFramebuffer should bypass the loadFunction read entirely and directly zero-out the target region in the mapped destination texture.
3. Zero-initialize Scratch Memory: As a defense-in-depth measure, ScratchBuffer::get should zero-initialize newly allocated heap memory to prevent leaking uninitialized PartitionAlloc/system memory, though this alone would not prevent leaking stale data from previous operations.

Evaluated with Chrome root at commit: 137d451a126685dd5010e6609db9f6d4a78d8234

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.