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: The SharedTextureMemory::Create overload for DMA-BUF descriptors in Dawn Vulkan does not validate the requested texture size against physical device limits. A compromised renderer could potentially pass arbitrary out-of-bounds size parameters through IPC to bypass high-level checks and trigger oversized VkImage creation. This might lead to driver-level integer overflows and heap-based memory corruption in the GPU process.

Affected files:

• third_party/dawn/src/dawn/native/vulkan/SharedTextureMemoryVk.cpp

Estimated timestamp from git blame: 2023-11-30

Potential Vulnerability Details

An issue has been identified in third_party/dawn/src/dawn/native/vulkan/SharedTextureMemoryVk.cpp where unvalidated size dimensions from external DMA-BUF descriptors can flow directly into Vulkan image creation.

When importing external textures via SharedTextureMemory::Create for SharedTextureMemoryDmaBufDescriptor, Dawn Vulkan copies the renderer-supplied descriptor->size parameters directly into properties.size without validating them against the physical device’s max texture limits (such as limits.v1.maxTextureDimension2D):

// From: third_party/dawn/src/dawn/native/vulkan/SharedTextureMemoryVk.cpp
ResultOrError<Ref<SharedTextureMemory>> SharedTextureMemory::Create(
    Device* device,
    StringView label,
    const SharedTextureMemoryDmaBufDescriptor* descriptor) {
#if DAWN_PLATFORM_IS(LINUX)
    ...
    DAWN_INVALID_IF(descriptor->size.depthOrArrayLayers != 1, "depthOrArrayLayers was not 1.");

    SharedTextureMemoryProperties properties;
    properties.size = {descriptor->size.width, descriptor->size.height,
                       descriptor->size.depthOrArrayLayers};

This is in contrast with the adjacent AHardwareBuffer overload (at lines 501-506), which explicitly validates the dimensions:

    DAWN_INVALID_IF(properties.size.width > limits.v1.maxTextureDimension2D,
                    "Resource width (%u) exceeds maxTextureDimension2D (%u).",
                    properties.size.width, limits.v1.maxTextureDimension2D);

Without this limit validation, the unchecked dimensions flow directly into CreateExternalVkImage and are used to populate the createInfo.extent parameter for vkCreateImage prior to any frontend validation:

    createInfo.extent = {properties.size.width, properties.size.height, 1};

Potential Attack Vector / Trigger Flow

Note: The following steps are theoretical, as our tooling cannot execute active proof-of-concept code.

1. A compromised renderer process could send a gpu::mojom::SharedImageInterface::CreateSharedImageWithBuffer IPC request, supplying a gfx::GpuMemoryBufferHandle of type NATIVE_PIXMAP with oversized dimensions (e.g., size = {0x7FFFFFFF, 0x7FFFFFFF}) and a matching large plane size.
2. The IPC handler’s high-level size verification (gfx::CanFitImageForSizeAndFormat) checks plane sizes against the image size. However, since the attacker controls the plane sizes in the Mojo message, they can bypass this validation.
3. The GPU process registers the backing, and subsequent WebGPU commands trigger DawnOzoneImageRepresentation::BeginAccess.
4. The representation calls device_.ImportSharedTextureMemory with the unvalidated dimensions.
5. In the Vulkan backend, vkCreateImage is called with the oversized extent (violating Vulkan VUID specifications). In production environments (where validation layers are disabled), certain Vulkan drivers may execute internal 32-bit arithmetic that overflows, leading to undersized memory allocations and subsequent heap corruption when the image is bound via vkBindImageMemory.

Proposed Fix

Enforce validation checks on properties.size in the SharedTextureMemoryDmaBufDescriptor overload of SharedTextureMemory::Create against physical device limits (limits.v1.maxTextureDimension2D and limits.v1.maxTextureArrayLayers), matching the validation present in the sibling AHardwareBuffer path.

Evaluated with Chrome root at commit: b1520ef4a76878853a31f0943b565e42060edec8

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.