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 integer underflow in Skia’s GrStagingBufferManager allows an out-of-bounds write in the GPU process. When a staging buffer’s offset is rounded up for alignment, it can exceed the total buffer size, causing the remaining size check to underflow and pass incorrectly.

Affected files:

• third_party/skia/src/gpu/ganesh/GrStagingBufferManager.cpp
• third_party/skia/src/gpu/ganesh/vk/GrVkGpu.cpp

Estimated timestamp from git blame: 2020-12-17

Description

A potential integer underflow vulnerability exists in GrStagingBufferManager::allocateStagingBufferSlice within Skia’s Ganesh Vulkan backend (third_party/skia/src/gpu/ganesh/GrStagingBufferManager.cpp).

When allocating a slice of a GPU staging buffer, the manager calculates an aligned offset and then verifies if the requested size fits within the remaining space:

size_t offset = ((currentOffset + requiredAlignment - 1)/requiredAlignment)*requiredAlignment;
if (totalBufferSize - offset >= size) {
    // ... returns a slice starting at fMapPtr + offset
}

If the alignment calculation causes the offset to exceed totalBufferSize, the expression totalBufferSize - offset (which utilizes unsigned size_t arithmetic) underflows to a very large positive value. This causes the bounds check to pass incorrectly. The function then returns a GrStagingBufferManager::Slice containing a CPU pointer (fOffsetMapPtr) that points past the end of the staging buffer’s CPU-mapped memory block.

While staging buffer sizes are typically powers of two, the requested alignment can be non-power-of-two. For example, GrVkGpu::uploadTexDataOptimal calculates the alignment as a multiple of 4 and the texel block size. For a 3-byte format (like VK_FORMAT_R8G8B8_UNORM, mapped to GrColorType::kRGB_888), the required alignment is 12 bytes.

If an attacker manipulates the staging buffer such that currentOffset is very close to the end of the buffer (e.g., 65535 out of a 65536-byte buffer), requesting a 12-byte alignment pushes the new offset to 65544. This triggers the underflow (65536 - 65544 >= size), returning an OOB pointer. Subsequent data copying via SkRectMemcpy will then write out of bounds.

Impact

This vulnerability allows an attacker to achieve an out-of-bounds write in the CPU-mapped memory of the GPU process. Because Skia’s Vulkan backend uses the Vulkan Memory Allocator (VMA), which sub-allocates from large contiguous memory blocks, this OOB write corrupts adjacent data within the same VMA block. An attacker with a compromised renderer process could groom this memory to overwrite sensitive GPU resources or internal metadata, potentially leading to arbitrary code execution and a Sandbox Escape.

Potential Reproduction Steps

Note: These steps trace the required flow through the codebase, though a functional proof-of-concept has not been executed.

1. From a compromised renderer, use the RasterInterface to create two SharedImage objects.
2. Create Image A with a 1-byte-per-pixel format (e.g., viz::SinglePlaneFormat::kALPHA_8) and dimensions of 65535x1 (requiring exactly 65535 bytes).
3. Create Image B with a format that maps to an optimal 3-byte Vulkan format on the target device (e.g., VK_FORMAT_R8G8B8_UNORM).
4. Queue a WritePixels command for Image A with 65535 bytes of data. This initializes a new 65536-byte staging buffer and leaves its currentOffset at 65535.
5. In the same IPC batch (to prevent the GrDirectContext from submitting and detaching the staging buffers), queue a WritePixels command for Image B with a malicious payload.
6. The GPU process processes Image B, requesting a slice with a 12-byte alignment. The offset calculates to 65544, triggering the underflow.
7. The attacker’s payload is copied out of bounds starting at offset 65544.

Suggested Fix

Add an explicit check to ensure offset does not exceed totalBufferSize before performing the subtraction in GrStagingBufferManager::allocateStagingBufferSlice:

size_t offset = ((currentOffset + requiredAlignment - 1)/requiredAlignment)*requiredAlignment;
if (offset <= totalBufferSize && totalBufferSize - offset >= size) {
    // ...
}

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.