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 vulnerability in ANGLE’s GL backend allows potential cross-origin pixel or uninitialized heap leaks by reusing dirty Display-pooled scratch buffers. If a native glReadPixels call fails silently in a release build, unmodified stale or uninitialized memory in the scratch buffer is uploaded to an attacker-controlled texture. This occurs because scratch buffers are shared across origins in a Display-level pool and are not zero-initialized upon retrieval.

Affected files:

• third_party/angle/src/libANGLE/renderer/gl/BlitGL.cpp

Estimated timestamp from git blame: 2020-02-03

Background

ANGLE’s GL backend uses a Display-level LIFO pool to share scratch buffers across contexts in the same GPU process. When a context is made non-current, its scratch buffer is returned to the Display pool via Context::unMakeCurrent (third_party/angle/src/libANGLE/Context.cpp:1154) and stored in Display::mScratchBuffers (third_party/angle/src/libANGLE/Display.cpp:2664). When another context becomes current and requests a scratch buffer, it can retrieve this exact buffer with its prior contents intact.

The Vulnerability

In BlitGL::copySubTextureCPUReadback (third_party/angle/src/libANGLE/renderer/gl/BlitGL.cpp:843-894), ANGLE obtains a scratch buffer without zero-filling it:

angle::MemoryBuffer *buffer = nullptr;
ANGLE_CHECK_GL_ALLOC(contextGL,
                     context->getScratchBuffer(sourceBufferSize + destBufferSize, &buffer));

It then performs a native glReadPixels call to fill sourceMemory:

ANGLE_GL_TRY(context, mFunctions->readPixels(readPixelsArea.x, readPixelsArea.y,
                                             readPixelsArea.width, readPixelsArea.height,
                                             readPixelsFormat, GL_UNSIGNED_BYTE, sourceMemory));

In Chrome production/release builds, ANGLE_GL_TRY compiles to a bare call with no error-checking or context-loss triggers:

#define ANGLE_GL_TRY(context, call) call

If the native glReadPixels call fails silently (due to GL_OUT_OF_MEMORY, an incomplete framebuffer state, or other driver-specific errors), the error is ignored, and the stale bytes in the scratch buffer remain unmodified.

Subsequently, CopyImageCHROMIUM reads the stale bytes from sourceMemory, converts them, and writes the results to destMemory, which is then uploaded directly to the attacker-controlled texture via texSubImage2D:

ANGLE_GL_TRY(context, mFunctions->texSubImage2D(..., destMemory));

Exposure Vectors

1. Cross-Origin Pixel Leak: The scratch buffer is reused across different WebGL contexts/origins without being cleared, meaning the attacker can read stale pixels belonging to a victim origin.
2. GPU Heap Leak: If the requested buffer size exceeds the pooled buffer’s size, a raw malloc() is executed via MemoryBuffer::resize (third_party/angle/src/common/MemoryBuffer.cpp:56). No zero-fill is performed, exposing raw, uninitialized GPU-process heap memory.

Potential Steps to Trigger

Note: These are suggested steps based on source code analysis; our tooling does not currently have the capability to execute code in a live environment.

1. A victim origin (Origin A) performs WebGL copy/cache operations, populating the scratch buffer with sensitive data, and is then unmade current.
2. The attacker origin (Origin B) becomes active and invokes CopySubTextureCHROMIUM on an sRGB destination texture, forcing ANGLE’s GL backend to take the CPU readback fallback path (copySubTextureCPUReadback).
3. The attacker’s context retrieves the dirty scratch buffer from the display pool.
4. The attacker induces a native driver error or GL_OUT_OF_MEMORY state to make glReadPixels fail silently.
5. The stale/uninitialized scratch buffer bytes are uploaded to the attacker’s texture, which the attacker reads back using standard WebGL readback APIs.

Recommended Fix

Before executing the copy operation in BlitGL::copySubTextureCPUReadback, initialize the scratch buffer to zero. This is similar to the mitigation applied in the D3D11 backend (third_party/angle/src/libANGLE/renderer/d3d/d3d11/Image11.cpp:434):

buffer->fill(0);

Evaluated with Chrome root at commit: e9507a33bb4148ee071aaaf8a7e9ad68770359bf

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.