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 Chrome Security team. Please see https://chromium.googlesource.com/chromium/src/+/main/docs/security/ai-generated-security-bugs-faq.md for more information.

Overview: The EnsureLoopForwardProgress AST pass in ANGLE’s Metal backend fails to detect mutations of global loop variables when they occur inside called functions. This allows crafted shaders to bypass infinite-loop mitigations, potentially leading to GPU process crashes or undefined behavior due to downstream compiler optimizations.

Affected files:

• third_party/angle/src/compiler/translator/tree_ops/msl/EnsureLoopForwardProgress.cpp
• third_party/angle/src/compiler/translator/tree_util/IntermTraverse.cpp

Estimated timestamp from git blame: 2025-05-22

Background

ANGLE’s Metal backend implements the EnsureLoopForwardProgress AST pass to mitigate issues where the Metal compiler (based on LLVM) optimizes away loops it perceives as infinite and side-effect-free. This optimization can lead to GPU process instability, hangs, or execution with undefined values (e.g., crbug.com/41486305). The pass inserts a volatile-write marker (ANGLE_loopForwardProgress()) into loops it cannot prove are finite.

Root Cause

The vulnerability is a potential interprocedural blind spot in the analysis performed within third_party/angle/src/compiler/translator/tree_ops/msl/EnsureLoopForwardProgress.cpp. The analysis incorrectly assumes a loop is finite if its counter variable is only modified by the loop’s own increment expression. This logic fails due to two factors:

1. Global Variable Acceptance: The computeFiniteLoopVariable() function identifies loop variables without verifying their storage qualifier. Consequently, file-scope global variables (EvqGlobal) are treated as if they were loop-local variables.
2. Intraprocedural Analysis Limitations: The EnsureLoopForwardProgressTraverser (inheriting from TLValueTrackingTraverser) only inspects the loop body intraprocedurally. When it encounters a function call (TIntermAggregate), it iterates over the arguments but does not inspect the callee’s definition for potential mutations of global variables.

Because the analysis does not account for global variables mutated inside called functions, it may incorrectly identify an infinite loop as finite and skip the insertion of the necessary ANGLE_loopForwardProgress() mitigation.

Potential Impact

An attacker could potentially craft a WebGL2 shader that implements an infinite loop using a global counter variable reset within a function call. If the EnsureLoopForwardProgress pass is bypassed, the resulting Metal Shading Language (MSL) code will lack the mitigation. The Metal compiler may then apply forward-progress assumptions, leading to undefined behavior or GPU process instability on macOS where ANGLE Metal is the default backend.

Suggested Proof of Concept

The following GLSL ES 3.00 shader illustrates the potential bypass. The analysis sees g++, but fails to see the mutation of g inside clobber():

#version 300 es
precision highp int;
int g;
void clobber() { g = 0; }
void main() {
    // The analysis may incorrectly conclude this loop is finite.
    for (g = 0; g != 10; g++) {
        clobber();
    }
}

Suggested Fix

Consider the following mitigations:

1. Modify computeFiniteLoopVariable() to only accept variables with the EvqTemporary qualifier, ensuring the loop variable is strictly local to the function.
2. Alternatively, update the traverser to conservatively mark the current loop as non-finite whenever a user-defined function call is encountered within the loop body.

Evaluated with Chrome root at commit: b3153093eb3c78c3e88ccf562bcbc20437a04b0e

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.