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 security workaround in Dawn for a known Mali GPU driver bug is incorrectly restricted to Android, leaving ChromeOS and Linux ARM systems vulnerable. Affected Mali drivers fail to zero-initialize workgroup memory, which allows malicious WebGPU shaders to leak cross-origin data from previous GPU dispatches. This results in a potential information disclosure vulnerability in the GPU Local Data Share (LDS).

Affected files:

• third_party/dawn/src/dawn/native/vulkan/PhysicalDeviceVk.cpp
• third_party/dawn/src/dawn/native/vulkan/ShaderModuleVk.cpp
• third_party/dawn/src/tint/lang/spirv/writer/raise/raise.cc
• third_party/dawn/src/tint/lang/spirv/writer/printer/printer.cc

Estimated timestamp from git blame: Unknown (Google3 checkout)

Description

Dawn (Chromium’s WebGPU implementation) relies on the VK_KHR_zero_initialize_workgroup_memory Vulkan extension to ensure that GPU workgroup memory (declared as var<workgroup> in WGSL) is zero-initialized between dispatches. This is a critical security requirement to prevent information leaks between different origins or processes sharing the same GPU hardware.

As documented in crbug.com/tint/2101, certain Mali GPU drivers are known to advertise support for this extension while failing to actually zero the memory. To mitigate this, Dawn is designed to disable the extension on affected Mali devices, forcing the Tint compiler to inject a manual zero-initialization loop into the generated SPIR-V.

However, the check used to enable this workaround in the Vulkan backend is compile-time restricted to Android via the IsAndroidARM() predicate, erroneously trusting the driver on other platforms like ChromeOS and Linux ARM.

Root Cause Analysis

In third_party/dawn/src/dawn/native/vulkan/PhysicalDeviceVk.cpp, the logic to disable the Vulkan zero-initialization extension occurs in SetupBackendDeviceToggles:

// PhysicalDeviceVk.cpp around line 1175
// Never use the extension on Mali devices due to a known bug (see crbug.com/tint/2101).
if (!GetDeviceInfo().HasExt(DeviceExt::ZeroInitializeWorkgroupMemory) ||
    GetDeviceInfo().zeroInitializeWorkgroupMemoryFeatures.shaderZeroInitializeWorkgroupMemory ==
        VK_FALSE ||
    IsAndroidARM() || gpu_info::IsImgTec(GetVendorId())) {
    deviceToggles->ForceSet(Toggle::VulkanUseZeroInitializeWorkgroupMemoryExtension, false);
}

The IsAndroidARM() method is platform-gated in the same file:

// PhysicalDeviceVk.cpp around line 1364
bool PhysicalDevice::IsAndroidARM() const {
#if DAWN_PLATFORM_IS(ANDROID)
    return gpu_info::IsARM(GetVendorId());
#else
    return false;
#endif
}

On non-Android platforms, such as ChromeOS or Linux ARM running on Mali GPUs, IsAndroidARM() returns false. This causes Dawn to use the buggy driver’s zero-initialization instead of Tint’s manual workaround.

When VulkanUseZeroInitializeWorkgroupMemoryExtension remains enabled:

1. ShaderModuleVk.cpp informs Tint that the driver will handle zero-initialization.
2. Tint’s SPIR-V pipeline (raise.cc) skips the ZeroInitWorkgroupMemory transform.
3. The SPIR-V printer (printer.cc) emits an OpVariable with an OpConstantNull initializer, which the buggy Mali driver fails to honor.

Impact

This is a cross-origin information disclosure vulnerability. A malicious website can use WebGPU compute shaders to read stale Local Data Share (LDS) contents from previous dispatches. Since the GPU process handles rendering and computation for multiple origins, an attacker could potentially capture sensitive data from other tabs or browser processes.

Potential Steps to Reproduce

1. Use an ARM-based Chromebook with a Mali GPU (e.g., MediaTek Kompanio series).
2. Navigate to a malicious website that initializes WebGPU.
3. The website submits a compute shader that declares a large var<workgroup> array.
4. The shader reads the contents of this array before writing to it and stores the results in a storage buffer.
5. The website reads back the storage buffer to inspect the uninitialized memory for cross-origin data.

Suggested Fix

Update the check in third_party/dawn/src/dawn/native/vulkan/PhysicalDeviceVk.cpp to use a platform-neutral check for ARM/Mali GPUs, such as gpu_info::IsARM(GetVendorId()), rather than relying on IsAndroidARM(). This ensures the security workaround is applied to all Mali devices regardless of the operating system.

Evaluated with Chrome root at commit: b3153093eb3c78c3e88ccf562bcbc20437a04b0e

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.