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: An out-of-bounds heap read potentially exists in XRCubeMap::updateWebGLEnvironmentCube when updating WebGL environment cube maps. The function uploads tightly-packed CPU-backed vectors to the page’s WebGL context without resetting stale pixel-store unpack parameters such as UNPACK_ROW_LENGTH. A web page could potentially pre-configure these parameters to cause the GLES2 client to over-read the allocated vector buffers into a JS-readable WebGL texture.

Affected files:

• third_party/blink/renderer/modules/xr/xr_cube_map.cc
• third_party/blink/renderer/modules/xr/xr_webgl_binding.cc

Estimated timestamp from git blame: 2020-01-16

Root Cause Analysis

In XRCubeMap::updateWebGLEnvironmentCube (located in third_party/blink/renderer/modules/xr/xr_cube_map.cc), raw pointers to tightly packed CPU buffers (Vector<uint16_t> or converted Vector<uint8_t>) are uploaded directly to the page’s WebGL context via gl->TexImage2D() without resetting the pixel-store unpack state.

If the calling page has previously configured ES3/WebGL2 unpack parameters (such as GL_UNPACK_ROW_LENGTH, GL_UNPACK_SKIP_ROWS, or GL_UNPACK_SKIP_PIXELS) using gl.pixelStorei(), these parameters remain active on the ContextGL(). When TexImage2D is invoked on the client-side command buffer wrapper (GLES2Implementation), the GLES2 client uses these parameters to compute the expected size of the input pointer:

PixelStoreParams params = GetUnpackParameters(k2D);
GLES2Util::ComputeImageDataSizesES3(width, height, 1, format, type, params, ...);

If UNPACK_ROW_LENGTH is configured to a value significantly larger than the texture width, the GLES2 client constructs an inflated base::span over the source pointer. During the pixel copy loop in CopyRectToBuffer, the client strides through the source pointer using the inflated row length, copying out-of-bounds heap memory into the transfer buffer used to upload the texture data.

Potential Trigger Steps

Note: These steps are theoretical/potential as our tooling does not currently run code to verify live exploits.

1. A page initializes an immersive-ar WebXR session with the light-estimation feature enabled.
2. The page initializes a WebGL2 rendering context with xrCompatible: true and configures gl.pixelStorei(gl.UNPACK_ROW_LENGTH, 4096).
3. An XRWebGLBinding is created for the session.
4. When a reflectionchange event occurs, the page calls binding.getReflectionCubeMap(lightProbe).
5. During updateWebGLEnvironmentCube, the GLES2 client processes the raw tightly packed buffer of size 16x16 under the assumption of a row stride of 4096 pixels. This results in an out-of-bounds read of the heap adjacent to the vector allocation.
6. The page binds the returned WebGL cube-map texture, attaches its faces to a framebuffer, and uses readPixels or shader sampling to read back the leaked heap memory.

Suggested Fix

To resolve this issue, Blink should ensure that the unpack parameters are temporarily reset to their default values prior to invoking raw-pointer uploads in the WebXR pipeline. This can be accomplished by instantiating a ScopedUnpackParametersResetRestore helper class on the rendering context inside XRCubeMap::updateWebGLEnvironmentCube before issuing the TexImage2D calls:

// Enforce a temporary reset of unpack parameters to avoid stale WebGL state over-reading CPU vectors
ScopedUnpackParametersResetRestore unpack_params(context);

This pattern matches the mitigation strategy employed in other Blink WebGL texture upload paths.

Evaluated with Chrome root at commit: 3947e01999a53d4e2382e39736cb79d79c7dffcf

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.