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: When using WebXR swap chains with wrapper textures (like texture arrays or cubemaps), the internal copy operation fails to reset the WebGL polygon mode state. An attacker can set the polygon mode to wireframe before the frame ends, causing the copy operation to only draw outlines. Because the destination texture skips clearing for optimization, this leaves the interior pixels uninitialized, potentially exposing stale cross-origin GPU memory to the VR headset.

Affected files:

• third_party/blink/renderer/modules/xr/xr_webgl_texture_array_swap_chain.cc
• third_party/blink/renderer/modules/xr/xr_webgl_cubemap_swap_chain.cc

Estimated timestamp from git blame: Unknown (Google3 checkout)

Description

A potential visual information disclosure vulnerability exists in the WebXR implementation when handling internal GPU copy operations for XRWebGLTextureArraySwapChain and XRWebGLCubemapSwapChain.

When a WebXR frame ends, the renderer performs a copy draw operation (DrawArraysInstancedANGLE or DrawElements) to blit content from a source wrapper texture into the inner swap chain texture. To optimize this process, the inner swap chain texture is configured with clear_on_access = false, relying on the assumption that the copy draw will overwrite the entire texture surface.

However, the C++ implementation inside OnFrameEnd() fails to explicitly reset the polygon mode state. The WEBGL_polygon_mode extension (backed by GL_ANGLE_polygon_mode) allows a page to change the polygon fill mode from the default GL_FILL_ANGLE to GL_LINE_ANGLE (wireframe) or GL_POINT_ANGLE. If a malicious page sets the polygon mode to GL_LINE_ANGLE before the frame ends, the internal copy draw operation will render wireframe quads instead of filled triangles.

Because the underlying texture was not cleared, and the copy draw only overwrites the edges of the quads, the interior pixels of the destination texture remain untouched. This leaves the texture containing uninitialized or stale VRAM from previous frames or cross-origin sessions. This partially uninitialized texture is then submitted to the VR compositor and displayed to the user, bypassing WebGL’s security guarantee that all buffers must be initialized before being accessible.

Potential Attacker Steps

(Note: These are potential steps as our tooling does not yet have the ability to run code.)

1. A WebGL2 page requests and acquires the WEBGL_polygon_mode extension.
2. The page initializes a WebXR session and creates a layer that utilizes a wrapper swap chain (e.g., setting textureType: "texture-array").
3. In a requestAnimationFrame callback, the page sets the polygon mode to wireframe: ext.polygonModeWEBGL(gl.FRONT_AND_BACK, gl.LINE_ANGLE).
4. The page renders its frame normally and returns from the callback.
5. The browser invokes XRWebGLTextureArraySwapChain::OnFrameEnd().
6. The C++ code prepares the copy operation but does not clear the polygon mode state. It executes gl->DrawArraysInstancedANGLE(), drawing a wireframe onto the inner swap chain texture.
7. The uninitialized interior pixels, containing stale VRAM, are passed to the VR compositor and displayed on the headset.

Proposed Fix

Both XRWebGLTextureArraySwapChain::OnFrameEnd() and XRWebGLCubemapSwapChain::OnFrameEnd() must explicitly reset the polygon mode to GL_FILL_ANGLE before performing the internal copy draws. Because the WebGL context state needs to remain consistent for the application, this state should be tracked and restored after the copy draw, similar to the existing handling for states like GL_DEPTH_TEST or GL_RASTERIZER_DISCARD.

Additionally, consider adding a DrawingBufferClientRestorePolygonMode() mechanism to the DrawingBuffer::Client interface to handle the restoration cleanly.

Evaluated with Chrome root at commit: 65b3256311f3ab6fb9870eaa522de7e6dd2663bb

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.