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: An out-of-bounds write vulnerability exists in ANGLE’s D3D11 backend when loading GL_LUMINANCE4_ALPHA4_OES texture data. The LoadLA8ToRGBA4 format conversion function uses an incorrect 4-byte output stride while writing to a buffer allocated for a 2-byte-per-pixel D3D11 staging texture. This mismatch allows a compromised renderer to trigger an out-of-bounds write in the GPU process, potentially leading to arbitrary code execution.

Affected files:

• third_party/angle/src/image_util/loadimage.cpp
• third_party/angle/src/libANGLE/renderer/d3d/d3d11/Image11.cpp

Estimated timestamp from git blame: 2024-12-03

Summary

A potential out-of-bounds (OOB) write vulnerability exists in the ANGLE D3D11 renderer when handling the GL_LUMINANCE4_ALPHA4_OES texture format.

The vulnerability stems from a logic error in the LoadLA8ToRGBA4 image conversion function, which assumes a 4-byte-per-pixel output stride when writing into a 16-bit (2-byte-per-pixel) staging buffer. A compromised renderer process can trigger this vulnerability to corrupt GPU process memory, potentially leading to arbitrary Remote Code Execution (RCE) and a sandbox escape.

Vulnerability Details

When a renderer creates a texture using glTexImage2D with the internal format GL_LUMINANCE4_ALPHA4_OES, type GL_UNSIGNED_BYTE, and format GL_LUMINANCE_ALPHA, the request is processed by the GPU process.

In third_party/angle/src/libANGLE/renderer/d3d/d3d11/Image11.cpp (Image11::loadData), ANGLE creates a CPU-writable D3D11 staging texture for the upload. If the underlying Windows hardware supports DXGI_FORMAT_B4G4R4A4_UNORM (a 16-bit, 2-byte-per-pixel format), the D3D11 staging texture is allocated with that format, resulting in a row pitch of approximately 2 * width bytes.

ANGLE then calls the format conversion function mapped to this operation: LoadLA8ToRGBA4 (third_party/angle/src/image_util/loadimage.cpp).

void LoadLA8ToRGBA4(..., uint8_t *output, ...)
{
    // ... loops for z and y ...
    for (size_t x = 0; x < width; x++)
    {
        uint8_t l       = source[2 * x + 0] >> 4;
        uint8_t a       = source[2 * x + 1] >> 4;
        // Bug: Uses a 4-byte stride for a 2-byte target format
        dest[4 * x + 0] = l | l << 4;
        dest[4 * x + 1] = l | a << 4;
    }
}

The LoadLA8ToRGBA4 loop uses an output index of 4 * x, meaning it expects an output buffer stride of 4 bytes per pixel. However, the output pointer (dest) points to the mapped memory of the DXGI_FORMAT_B4G4R4A4_UNORM staging texture, which is only 2 * width bytes large per row.

As x iterates past width / 2, the dest[4 * x + 0] index exceeds the bounds of the driver-allocated staging buffer, resulting in a sparse out-of-bounds write of 2 bytes every 4 bytes. For example, a texture width of 8192 will result in writing roughly 16KB past the end of the staging buffer.

Reachability and Exploitation

This issue can be triggered from a compromised renderer process on Windows devices that support the GL_OES_required_internalformat extension and the DXGI_FORMAT_B4G4R4A4_UNORM hardware format.

The out-of-bounds write occurs in memory allocated by the graphics driver (mapped via D3D11_MAP_WRITE), not via Chromium’s PartitionAlloc. Therefore, memory safety mitigations like MiraclePtr (BRP) do not prevent exploitation.

By carefully grooming the GPU process’s driver-mapped memory space prior to issuing the malicious glTexImage2D call, an attacker could position critical metadata or pointers immediately following the staging texture allocation. The attacker has partial control over the out-of-bounds data via the source luminance and alpha values, allowing them to overwrite critical structures and achieve a sandbox escape.

(Note: These are potential steps an attacker might follow; our automated tooling has not executed a live proof-of-concept exploit.)

1. Gain Renderer Execution: Exploit a V8 or Blink vulnerability to run arbitrary code in the sandboxed renderer.
2. Verify Extension: Query for GL_OES_required_internalformat support.
3. Heap Grooming: Use WebGL commands to groom the driver’s mapped memory, placing target objects adjacent to the expected allocation size of the staging buffer.
4. Trigger OOB Write: Call glTexImage2D with GL_LUMINANCE4_ALPHA4_OES, a width of 8192, height of 1, and a payload crafted to cleanly overwrite target objects during the OOB write phase.
5. Achieve RCE: Trigger the corrupted objects to hijack control flow in the GPU process.

Proposed Fix

In third_party/angle/src/image_util/loadimage.cpp, update the indexing in LoadLA8ToRGBA4 to correctly use a 2-byte output stride for the 16-bit format. It is highly recommended to cast the dest pointer to a uint16_t* (as done in other 16-bit conversion functions like LoadRGBA8ToRGBA4) to avoid stride confusion.

// Suggested Fix in loadimage.cpp:
uint16_t *dest = priv::OffsetDataPointer<uint16_t>(output, y, z, outputRowPitch, outputDepthPitch);
for (size_t x = 0; x < width; x++)
{
    uint16_t l = source[2 * x + 0] >> 4;
    uint16_t a = source[2 * x + 1] >> 4;
    dest[x] = (l | (l << 4)) | ((l | (a << 4)) << 8);
}

(Alternatively, adjust the byte offsets to dest[2 * x + 0] and dest[2 * x + 1] while keeping dest as uint8_t*).

Evaluated with Chrome root at commit: 137d451a126685dd5010e6609db9f6d4a78d8234

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.