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: A compromised renderer can supply a fabricated gpu::mojom::VulkanYCbCrInfo struct with modified format_features via a TransferableResource. Because compatibility checks in Viz deliberately ignore filter mismatches and Dawn lacks capability validation, this can result in the GPU process invoking vkCreateSamplerYcbcrConversion with invalid parameters. This violates Vulkan VUIDs and potentially triggers driver undefined behavior in the unsandboxed GPU process on Android.

Affected files:

• third_party/dawn/src/dawn/native/Sampler.cpp
• third_party/dawn/src/dawn/native/vulkan/UtilsVulkan.cpp
• gpu/ipc/common/vulkan_ycbcr_info_mojom_traits.h
• components/viz/service/display_embedder/image_context_impl.cc
• gpu/command_buffer/service/shared_image/shared_image_format_service_utils.cc
• components/viz/service/display/external_use_client.cc
• components/viz/service/display_embedder/skia_output_surface_impl.cc

Estimated timestamp from git blame: 2019-05-09

Description

On Android with Skia Graphite and Dawn compositing enabled, a compromised renderer can potentially trigger Vulkan driver undefined behavior inside the GPU process. The issue stems from a lack of validation on the renderer-supplied gpu::mojom::VulkanYCbCrInfo structure transmitted via Mojo IPC within a TransferableResource.

Specifically, the renderer can fabricate the format_features field to claim support for VK_FORMAT_FEATURE_SAMPLED_IMAGE_YCBCR_CONVERSION_LINEAR_FILTER_BIT when the underlying hardware format does not support it. This fabricated information travels through the compositor’s promise texture pipeline and is eventually passed directly to the Vulkan driver function vkCreateSamplerYcbcrConversion with chromaFilter = VK_FILTER_LINEAR.

Potential Attack Chain / Technical Flow

1. IPC Entry: A compromised renderer constructs a viz::CompositorFrame containing a TransferableResource referencing a valid SharedImage mailbox.
2. Fabricating Features: The renderer populates ycbcr_info (gpu.mojom.VulkanYCbCrInfo) with matching format identifiers but sets format_features to include VK_FORMAT_FEATURE_SAMPLED_IMAGE_YCBCR_CONVERSION_LINEAR_FILTER_BIT (lying about linear chroma filter support).
3. Mojo Deserialization: In the GPU process, the frame is deserialized. The trait implementation in gpu/ipc/common/vulkan_ycbcr_info_mojom_traits.h:45-71 performs zero validation on the deserialized format_features field.
4. Compatibility Bypass: When verifying the frame, ImageContextImpl::BeginAccessIfNecessaryInternal in components/viz/service/display_embedder/image_context_impl.cc:452 invokes DawnYCbCrVkDescriptorsAreCompatible. This compatibility check deliberately skips comparisons of vkChromaFilter (lines 76-79) to avoid dropping video frames.
5. Immutable Sampler Packing: During draw recording, DawnCaps::getImmutableSamplerInfo in third_party/skia/src/gpu/graphite/dawn/DawnCaps.cpp:620-632 extracts and packs the promise texture’s YCbCr descriptor (including the fake linear filter mode).
6. Chaining and Sampler Creation: In third_party/skia/src/gpu/graphite/dawn/DawnSampler.cpp:95-96, the descriptor is unpacked and chained to the Dawn sampler descriptor. Dawn’s frontend validation in ValidateSamplerDescriptor (third_party/dawn/src/dawn/native/Sampler.cpp:73-91) fails to verify whether the format actually supports the requested filter mode.
7. VUID Violation: In Dawn’s Vulkan backend, CreateSamplerYCbCrConversion in third_party/dawn/src/dawn/native/vulkan/UtilsVulkan.cpp:463 calls the Vulkan driver API vkCreateSamplerYcbcrConversion with chromaFilter = VK_FILTER_LINEAR. This violates Vulkan validation rule VUID-VkSamplerYcbcrConversionCreateInfo-chromaFilter-01657 and triggers driver undefined behavior.

Note: Because these steps represent potential execution paths identified via static code analysis, and we currently do not have a running proof-of-concept exploit, the behavior may vary depending on the specific Vulkan driver implementation.

Security Impact

On Android, the GPU process runs unsandboxed by default (the kAndroidGpuSandbox feature flag is disabled by default). If an attacker can leverage this Vulkan driver undefined behavior to achieve out-of-bounds memory access or corruption within the GPU process, it could potentially lead to arbitrary code execution outside the renderer’s sandbox.

Suggested Fix

To remediate this issue, validate that the renderer-supplied filter parameters are compatible with the actual physical hardware format capabilities before utilizing them to create Vulkan samplers.

Specifically, inside ImageContextImpl::BeginAccessIfNecessaryInternal or DawnYCbCrVkDescriptorsAreCompatible in components/viz/service/display_embedder/image_context_impl.cc, verify that if the promise texture descriptor requests wgpu::FilterMode::Linear for vkChromaFilter, the fulfillment texture’s actual YCbCr descriptor also supports linear filtering. If there is a capability mismatch (i.e., the fulfillment format lacks the required feature bit but the promise texture claimed it), reject the draw or fallback safely instead of passing the incompatible configuration to Dawn and the Vulkan driver.

Evaluated with Chrome root at commit: d8b226a3be7c9c1ac9240c09e14698866c82e4ac

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.