Report description

ANGLE Vulkan: readPixelsImpl 32-bit overflow in staging buffer size calculation

Bug location

Where do you want to report your vulnerability?

Chrome VRP – Report security issues affecting the Chrome browser. See program rules

Which URL (or repository) have you found the vulnerability in?

https://chromium.googlesource.com/angle/angle

The problem

Please describe the technical details of the vulnerability

The problem

ImageHelper::readPixelsImpl in the ANGLE Vulkan backend computes a staging buffer size using 32-bit arithmetic that overflows before widening to size_t. This is a missed instance from the CVE-2026-3536 fix (commit 56c952c, Bug: chromium:487208468).

Vulnerable code — src/libANGLE/renderer/vulkan/vk_helpers.cpp, line 11502:

size_t allocationSize = readFormat->pixelBytes * area.width * area.height;

Type analysis:

• readFormat->pixelBytes: GLuint (32-bit unsigned)
• area.width, area.height: int (32-bit signed)
• The multiplication evaluates entirely in 32-bit, wrapping before assignment to size_t
• For RGBA32F (16 bytes/pixel) at 16384×16384: 16 × 16384 × 16384 = 4,294,967,296 wraps to 0

Fixed instance in same file (commit 56c952c, line 9414):

const size_t bufferSize = static_cast<size_t>(clippedRectangle.width) *
                          static_cast<size_t>(clippedRectangle.height) *
                          storageFormat.pixelBytes;

The static_cast<size_t>() pattern was applied to stageSubresourceUpdateFromFramebuffer but not to readPixelsImpl in the same file.

Code path: Reachable via copyTexSubImage2D when both GPU transfer and GPU draw copy paths fail:

gl.copyTexSubImage2D(target, level, 0, 0, 0, 0, 16384, 16384)
  → TextureVk::copySubImageImpl()
    → [transfer copy fails: format mismatch]
    → [draw copy fails: dest lacks VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BIT]
    → stageSubresourceUpdateFromFramebuffer() [CPU fallback]
      → ImageHelper::readPixelsImpl()         [line 11502, OVERFLOW]

The internal readPixelsImpl call from stageSubresourceUpdateFromFramebuffer constructs its own PackPixelsParams with packBuffer = nullptr, bypassing PBO validation and always reaching the CPU Readback section containing the overflow.

Practical exploitability is low. The CPU fallback requires a destination format lacking VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BIT for a 16-byte-per-pixel format. All three WebGL 2 candidates (RGBA32F/UI/I) have COLOR_ATTACHMENT support on 97–99% of Vulkan devices. This is primarily a defense-in-depth fix.

Suggested fix:

size_t allocationSize = static_cast<size_t>(readFormat->pixelBytes) *
                        static_cast<size_t>(area.width) *
                        static_cast<size_t>(area.height);

Additional missed instances (same 32-bit overflow pattern):

• D3D11: Image11.cpp:428
• GL: BlitGL.cpp:833, TextureGL.cpp:750

Impact analysis

Impact analysis

This vulnerability has low practical exploitability on current hardware. An attacker would need to target the ~1–3% of Vulkan devices where 16-byte-per-pixel formats lack COLOR_ATTACHMENT support, and those devices typically have MAX_TEXTURE_SIZE below the threshold needed for overflow.

If the overflow were triggered, it would produce a zero-sized Vulkan staging buffer followed by a full-size GPU DMA write, causing potential out-of-bounds writes in renderer GPU process memory.

The primary value is defense-in-depth: the overflow could become reachable through future code changes, new GPU drivers, or new internal callers of readPixelsImpl that bypass validation. The fix is a one-line cast matching the pattern already applied elsewhere in the same file.

The cause

What version of Chrome have you found the security issue in?

145.0.7632.160 + stable

Is the security issue related to a crash?

Yes, it is related to a crash.

Choose the type of vulnerability

Other

How would you like to be publicly acknowledged for your report?

mikey233 of HackerOne