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 Chrome Security team. Please see https://chromium.googlesource.com/chromium/src/+/main/docs/security/ai-generated-security-bugs-faq.md for more information.

Overview: A logic error in the Vulkan Memory Allocator (VMA) allows its mapping hysteresis state machine to become desynchronized if a vkMapMemory call fails. This causes subsequent mapping requests to return success with a NULL base pointer, which downstream components like Skia offset and write to, leading to arbitrary memory corruption in the GPU process.

Affected files:

• third_party/vulkan_memory_allocator/include/vk_mem_alloc.h
• third_party/skia/src/gpu/ganesh/vk/GrVkBuffer.cpp
• third_party/skia/src/gpu/ganesh/vk/GrVkGpu.cpp
• third_party/skia/src/gpu/graphite/vk/VulkanBuffer.cpp
• third_party/angle/src/libANGLE/renderer/vulkan/vk_renderer.cpp

Estimated timestamp from git blame: 2022-06-14

Summary

A potential vulnerability exists in the Vulkan Memory Allocator (VMA) library used by Chrome’s GPU process (via Skia and ANGLE). When VMA’s mapping hysteresis feature is enabled (which is the default), a failed memory mapping request leaves the internal state machine in a desynchronized state. Subsequent requests to map the same memory block will hit a fast path, falsely returning VK_SUCCESS but providing a NULL base pointer. Because VMA suballocations include an offset, downstream callers receive a non-NULL pointer (e.g., NULL + offset) and bypass standard null checks, leading to wild memory writes of attacker-controlled data.

Root Cause Analysis

In third_party/vulkan_memory_allocator/include/vk_mem_alloc.h, the VmaDeviceMemoryBlock::Map() function manages persistent mapping state and hysteresis.

// third_party/vulkan_memory_allocator/include/vk_mem_alloc.h
VmaMutexLock lock(m_MapAndBindMutex, hAllocator->m_UseMutex);
const uint32_t oldTotalMapCount = m_MapCount + m_MappingHysteresis.GetExtraMapping();
m_MappingHysteresis.PostMap(); // State is advanced here

if (oldTotalMapCount != 0) {
    // Fast path: assumes memory is already mapped
    m_MapCount += count;
    VMA_ASSERT(m_pMappedData != VMA_NULL);
    if (ppData != VMA_NULL) { *ppData = m_pMappedData; }
    return VK_SUCCESS;
} else {
    VkResult result = (*hAllocator->GetVulkanFunctions().vkMapMemory)(..., &m_pMappedData);
    if (result == VK_SUCCESS) {
        // ...
        m_MapCount = count;
    }
    return result; // Failure path: NO rollback of PostMap()
}

The PostMap() function increments counters. If a threshold is reached, it sets m_ExtraMapping = 1, simulating an active map to keep memory resident. However, oldTotalMapCount is calculated before PostMap() executes.

If the subsequent vkMapMemory call fails (e.g., due to host memory exhaustion), the function returns the error but fails to revert the m_ExtraMapping state change made by PostMap(). The block is now desynchronized: m_ExtraMapping is 1, but m_pMappedData remains VMA_NULL.

On the next Map() call, oldTotalMapCount evaluates to 1. The code enters the fast path, bypassing vkMapMemory, and returns VK_SUCCESS while assigning VMA_NULL to *ppData. (Note: The VMA_ASSERT is compiled out in release builds).

Exploitation Scenario

An attacker could potentially exploit this from a malicious webpage using WebGL or WebGPU:

1. The attacker creates a host-mappable buffer (the “victim”), which VMA suballocates from a larger VmaDeviceMemoryBlock with a non-zero offset (e.g., 0x8000000).
2. The attacker updates the buffer multiple times, causing repeated map/unmap cycles. This increments the hysteresis counters until they are one step away from triggering m_ExtraMapping = 1.
3. The attacker exhausts host virtual address space in the GPU process by allocating numerous large textures.
4. The attacker issues another buffer update. PostMap() sets m_ExtraMapping = 1, but vkMapMemory fails due to memory exhaustion. The error is returned, and state is desynchronized.
5. The attacker frees the textures to restore memory availability.
6. The attacker issues a final update to the victim buffer with a malicious payload. VMA hits the fast path and returns VK_SUCCESS with a base pointer of 0x0.
7. VmaAllocator_T::Map() adds the suballocation offset: *ppData = 0x0 + 0x8000000.
8. Skia’s GrVkBuffer::onUpdateData checks if (!fMapPtr). Since 0x8000000 is not null, the check passes.
9. Skia executes memcpy(fMapPtr + offset, src, size), copying attacker data directly to 0x8000000.

By spraying the address space (especially on 32-bit platforms like Android, where the GPU process is unsandboxed), the attacker can ensure this low address maps to critical data structures, leading to arbitrary code execution.

Note: These steps are suggested based on code analysis; a full proof-of-concept has not yet been executed by our tooling.

Suggested Fix

In VmaDeviceMemoryBlock::Map(), if vkMapMemory fails, the state change introduced by m_MappingHysteresis.PostMap() must be rolled back. Alternatively, PostMap() should only be called after vkMapMemory succeeds.

Evaluated with Chrome root at commit: a1e33f5848218e21d4a16ae2c1bc94e815c30c7f

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.