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: ANGLE’s GLSL parser fails to validate the size of interface blocks (UBOs/SSBOs), allowing arbitrarily large arrays to bypass the 2GB compiler limit check. When ANGLE-on-GL passes these unvalidated oversized declarations to the native OpenGL driver during shader compilation, it can trigger 32-bit integer overflows in the driver’s memory layout calculations. This driver-level overflow could lead to out-of-bounds memory access and potential Remote Code Execution in the GPU process.

Affected files:

• third_party/angle/src/compiler/translator/ParseContext.cpp
• third_party/angle/src/compiler/translator/glsl/OutputGLSLBase.cpp
• third_party/angle/src/libANGLE/renderer/gl/ShaderGL.cpp

Estimated timestamp from git blame: 2026-01-21

Summary

In ANGLE’s GLSL translator, the parsing logic for interface blocks (uniform Block { ... } and buffer Block { ... }) entirely bypasses the checkVariableSize() security mitigation. This mitigation was specifically designed to prevent integer overflows in backends and native graphic drivers by restricting shader variables to a 2GB limit. By bypassing this check, malicious shaders can declare interface blocks large enough to trigger 32-bit integer overflows when the native OpenGL driver processes the memory layout, potentially leading to heap corruption and Remote Code Execution (RCE) in the GPU process.

Technical Details

The vulnerability stems from multiple oversights in third_party/angle/src/compiler/translator/ParseContext.cpp:

1. Bypass of Validation Check: When parsing an interface block, TParseContext::addInterfaceBlock() directly instantiates a new TVariable and calls declareIRVariable(). It does not call declareVariable(), which is the standard function that invokes checkVariableSize().
2. Flawed Size Calculation: Even if checkVariableSize() were invoked, its helper function CalculateVariableSize() ignores EbtInterfaceBlock. While it correctly calculates the size of EbtStruct by iterating over its fields, it falls through to a default case for EbtInterfaceBlock, severely undercalculating its size.
3. Unbounded Array Parsing: The array sizes within interface blocks are processed by checkIsValidArraySize(), which checks that the size is a non-negative 32-bit integer but fails to enforce any upper memory boundary.

On the ANGLE-on-GL backend (used by default on ChromeOS and available on Linux/Android), unused interface blocks are intentionally not pruned from the AST (exempted in PruneNoOps). Thus, OutputGLSLBase::declareInterfaceBlock emits the full, oversized declaration into the translated GLSL string.

When this translated GLSL is passed to the native OpenGL driver via glCompileShader(), the native driver attempts to calculate layout sizes and offsets for the interface block members. A massive array (e.g., mat4 m[67108864];) exactly wraps a 32-bit unsigned integer boundary (67108864 * 64 bytes = 4,294,967,296 bytes = 0 modulo 2^32). This causes malformed internal driver states, such as 0-byte allocations or overlapping offsets, leading to out-of-bounds reads/writes in the GPU process.

Note: ANGLE has a link-time size validation (ValidateInterfaceBlocks), but this only executes during glLinkProgram(). The native driver is exposed to the malformed shader during the earlier glCompileShader() call, rendering the link-time validation ineffective against driver-level compiler exploitation.

Potential Reproduction Steps

Note: These are suggested steps to trigger the vulnerability. Our tooling agent does not have the ability to run code to confirm the resulting driver crash/exploit locally.

1. Initialize a WebGL 2 context on a system using the ANGLE-on-GL backend (e.g., ChromeOS or Linux with --use-angle=gl).
2. Create a fragment shader containing a massive UBO or SSBO declaration designed to overflow a 32-bit layout calculation, for example:

   #version 300 es
   precision highp float;
   uniform Huge { mat4 m[67108864]; } b;
   out vec4 c;
   void main() { c = vec4(1.0); }
   

3. Call gl.shaderSource() and gl.compileShader().
4. Observe that the massive block declaration passes ANGLE’s parsing and reaches the native graphics driver, potentially causing a crash or enabling heap corruption in the GPU process.

Suggested Fix

1. Modify TParseContext::addInterfaceBlock() to explicitly call checkVariableSize() for the newly created interface block instance variable before adding it to the AST.
2. Update CalculateVariableSize() in ParseContext.cpp to properly handle EbtInterfaceBlock types. It should iterate over the fields of the interface block and sum their sizes, identical to the logic already in place for EbtStruct.
3. Consider adding a maximum bound check directly inside checkIsValidArraySize() as an additional defense-in-depth measure.

Evaluated with Chrome root at commit: ff3d2b74fa39431785bd60e51463b08fcc71ee33

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.