PatchGap
Chrome · GPU

CVE-2026-9898

Input Validation in GPU
High watch ✔︎ verified CVSS 8.3 chrome Input Validation 📄 Reporter bug report 🔧 Commit mapped

Overview

High
Severity
8.3
CVSS
No
Exploited ITW
Fixed
Fix Status
ImpactInsufficient validation of untrusted input in GPU
DescriptionInsufficient validation of untrusted input in GPU
ComponentGPU
Bug ClassInput Validation
Action tierwatch — ub-class only — no demonstrated corruption path — factors set by independent review by AI
Computed by PatchGap's deterministic exploitability ruler from the fixing commit. patch-now = RCE-class & attacker-reachable in a default config, or exploited in the wild; watch = real security signal below that bar; noise = no security relevance.
Independent review by AIConfirmed
A second, independent AI reviewer (not a human) re-derived this analysis from the fixing commit and the vendor advisory, looking for errors.
Tracker496282591
Fix commit2540f0d8870b (chromium/src) +16/-0
CWECWE-20 (Improper input validation)
CVSS vectorCVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H
CISA KEVNot listed
CreditedGoogle
Reported2026-03-25 (per vendor advisory)
Fix landed2026-05-07 (public git)
Disclosed2026-05-27
Patch gap20 days — fix public in source before the advisory

Background

`gpu::VulkanYCbCrInfo`
a GPU-side struct carrying Vulkan YCbCr sampler-conversion parameters that originate across an IPC boundary.
`StructTraits<...VulkanYCbCrInfoDataView, gpu::VulkanYCbCrInfo>::Read`
the Mojo deserializer that fills a gpu::VulkanYCbCrInfo from an incoming IPC message (vulkan_ycbcr_info_mojom_traits.h:45).
Mojo `StructTraits::Read` contract
returning false rejects the message as invalid and (per Mojo) tears down the misbehaving connection, so it is the designated place for cross-process validation.

Root Cause Analysis

The Mojo struct carries the Vulkan enum parameters as raw uint32_t/uint64_t fields rather than typed Mojo enums, so Mojo’s built-in enum validation never runs. In the pre-fix Read, every incoming field is copied straight into the out struct — out->suggested_ycbcr_model = data.suggested_ycbcr_model(); and the sibling assignments at vulkan_ycbcr_info_mojom_traits.h:49-52 — and the function then return true; at vulkan_ycbcr_info_mojom_traits.h:54 with no range check. The invariant that should hold — that these fields only ever hold valid Vulkan enum values before they are handed to driver code — is therefore never enforced at the trust boundary.

The patch restores it by adding, after the assignments, explicit comparisons against the maximum valid enum constants (VK_SAMPLER_YCBCR_MODEL_CONVERSION_YCBCR_2020 = 4, VK_SAMPLER_YCBCR_RANGE_ITU_NARROW = 1, VK_CHROMA_LOCATION_MIDPOINT = 1) and returning false if suggested_ycbcr_model, suggested_ycbcr_range, suggested_xchroma_offset, or suggested_ychroma_offset exceeds its bound (added diff lines at @@ -51,6). This tightens the check: a message whose enum fields are out of range is now rejected instead of accepted. The reporter’s downstream call chain through Dawn/Skia is not present in the shown material, so how those values reach vkCreateSamplerYcbcrConversion is (inferred).

Key insight
Because the YCbCr enum parameters crossed IPC as plain integers, the deserializer accepted any value without bounds checks; the fix adds explicit max-value validation in Read and rejects the message when any of the four enum fields is out of range.

Attack Path

  1. Compromised renderer crafts values A renderer under attacker control populates a gpu::VulkanYCbCrInfo with enum fields set far above their valid ranges (e.g. suggested_ycbcr_model = a large integer). (inferred trigger per reporter)
  2. IPC deserialization accepts them The GPU process runs Read, which pre-fix copies the raw values and returns true unconditionally (vulkan_ycbcr_info_mojom_traits.h:49-54).
  3. Values flow to the Vulkan driver The unvalidated enums are passed down to Vulkan sampler-conversion creation, where an out-of-range enum can cause out-of-bounds access in driver code. (inferred; downstream path not in shown material)
  4. Memory corruption in the GPU process The driver’s unchecked use of the bogus enum yields a potential out-of-bounds read/write in the privileged GPU process. (inferred)

Impact Assessment

A compromised or malicious renderer could feed out-of-range Vulkan enum values into the GPU process, which pre-fix forwarded them toward the Vulkan driver without validation, potentially causing out-of-bounds memory access in that privileged process. The advisory rates this high severity and records no in-the-wild exploitation; escalation to a full sandbox escape or code execution is (inferred).

Files Changed

  • gpu/ipc/common/vulkan_ycbcr_info_mojom_traits.h

Audit Directions

  • Enums carried as raw integers over IPC
    Any Mojo field typed as uint32_t/uint64_t that is semantically an enum bypasses Mojo’s enum validation and must be range-checked in its StructTraits::Read.
  • Unvalidated data forwarded to drivers
    Treat values that flow from a less-privileged process into GPU driver APIs as untrusted until bounds-checked at the deserialization boundary.
  • Incomplete field validation
    When adding validation, confirm every field that reaches sensitive code is covered; here image_format, external_format, and format_features are still copied without checks.

Patch

view commit
From 2540f0d8870b855bd58a696ccfd9c213a2e95c88 Mon Sep 17 00:00:00 2001
From: Vasiliy Telezhnikov <vasilyt@chromium.org>
Date: Thu, 07 May 2026 13:33:56 -0700
Subject: [PATCH] Validate YCbCr info enum values

Due to dependency issues, we passed uint32_t values instead of enum
historically, until we can resolve this we should validate against known
values.

Bug: 496282591,496565479
Change-Id: I36e3429b19cd71c32e4317cad24dfb1299c3406f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7823022
Reviewed-by: Joe Mason <joenotcharles@google.com>
Commit-Queue: Vasiliy Telezhnikov <vasilyt@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1627197}
---

diff --git a/gpu/ipc/common/vulkan_ycbcr_info_mojom_traits.h b/gpu/ipc/common/vulkan_ycbcr_info_mojom_traits.h
index e349c8bd..0048aef 100644
--- a/gpu/ipc/common/vulkan_ycbcr_info_mojom_traits.h
+++ b/gpu/ipc/common/vulkan_ycbcr_info_mojom_traits.h
@@ -51,6 +51,22 @@
     out->suggested_xchroma_offset = data.suggested_xchroma_offset();
     out->suggested_ychroma_offset = data.suggested_ychroma_offset();
     out->format_features = data.format_features();
+
+    // Values from Vulkan definitions, because we can't easy depend on vulkan
+    // here.
+    // https://source.chromium.org/chromium/chromium/src/+/main:third_party/vulkan-headers/src/include/vulkan/vulkan_core.h;drc=f6a6f7ab165cedbfa2a7d0c93fe27a2d01ce09c8;l=5438
+    const uint32_t VK_SAMPLER_YCBCR_MODEL_CONVERSION_YCBCR_2020 = 4;
+    const uint32_t VK_CHROMA_LOCATION_MIDPOINT = 1;
+    const uint32_t VK_SAMPLER_YCBCR_RANGE_ITU_NARROW = 1;
+
+    if (out->suggested_ycbcr_model >
+            VK_SAMPLER_YCBCR_MODEL_CONVERSION_YCBCR_2020 ||
+        out->suggested_ycbcr_range > VK_SAMPLER_YCBCR_RANGE_ITU_NARROW ||
+        out->suggested_xchroma_offset > VK_CHROMA_LOCATION_MIDPOINT ||
+        out->suggested_ychroma_offset > VK_CHROMA_LOCATION_MIDPOINT) {
+      return false;
+    }
+
     return true;
   }
 };
Loading diff…

Original Bug Report

reported by vm...@google.com

Potential GPU Sandbox Escape via unvalidated VulkanYCbCrInfo in IPC

Project Fortify, an experimental security project, has identified the following potential security issue.

Overview: The GPU process fails to validate Vulkan YCbCr conversion parameters received from the renderer via IPC. A compromised renderer can send out-of-bounds enum values that are passed directly to the Vulkan driver via Dawn or Skia. This can potentially trigger out-of-bounds memory access within the driver, leading to a GPU sandbox escape.

Affected files:

  • gpu/ipc/common/vulkan_ycbcr_info_mojom_traits.h
  • gpu/command_buffer/service/shared_image/shared_image_format_service_utils.cc
  • components/viz/service/display_embedder/skia_output_surface_impl.cc

Estimated timestamp from git blame: 2019-08-13

Description

There is a potential sandbox escape vulnerability where a compromised Renderer process can send out-of-bounds Vulkan enum values to the GPU process via IPC. When these values are passed to the underlying Vulkan driver, they can cause undefined behavior (such as out-of-bounds array indexing), potentially allowing the attacker to execute arbitrary code within the highly privileged GPU process.

Root Cause

The gpu.mojom.VulkanYCbCrInfo Mojo struct defines Vulkan enum parameters (like suggested_ycbcr_model and suggested_ycbcr_range) as opaque uint32 and uint64 fields instead of strongly-typed Mojo enums. Consequently, Mojo’s automatic enum validation is bypassed.

During deserialization in the GPU process, StructTraits<gpu::mojom::VulkanYCbCrInfoDataView, gpu::VulkanYCbCrInfo>::Read (gpu/ipc/common/vulkan_ycbcr_info_mojom_traits.h) unconditionally copies these raw integer values into the C++ gpu::VulkanYCbCrInfo struct without any bounds checking.

Vulnerable Code Path

  1. A compromised renderer embeds a malicious gpu::VulkanYCbCrInfo inside a viz::TransferableResource and sends it to the Viz service in the GPU process.
  2. In Viz, when compositing on Android with the Graphite/Dawn backend, SkiaOutputSurfaceImpl::MakePromiseSkImageSinglePlane is called to sample the texture.
  3. The unvalidated ycbcr_info is passed to gpu::GraphitePromiseTextureInfo, which calls ToDawnYCbCrVkDescriptor (gpu/command_buffer/service/shared_image/shared_image_format_service_utils.cc).
  4. The raw uint32_t values are copied directly into a wgpu::YCbCrVkDescriptor.
  5. Dawn processes this descriptor in dawn::native::vulkan::CreateSamplerYCbCrConversionCreateInfo (third_party/dawn/src/dawn/native/vulkan/UtilsVulkan.cpp). It blindly static_casts the out-of-bounds integers to Vulkan enums (e.g., VkSamplerYcbcrModelConversion) and passes them to the vkCreateSamplerYcbcrConversion Vulkan API call.
  6. Note: The Ganesh path is similarly vulnerable via gpu::CreateVulkanYcbcrConversionInfo in gpu/command_buffer/service/skia_utils.cc.

Production Vulkan drivers typically lack robust bounds checking for API enums due to performance reasons. Passing invalid enums is known to cause drivers to perform out-of-bounds array reads or writes when looking up internal formats or conversion matrices.

Potential Attacker Steps

Note: These are potential steps to trigger the vulnerability, as this AI agent does not currently have the capability to execute code or build a working Proof of Concept.

  1. Achieve arbitrary code execution within the Renderer process sandbox.
  2. Craft a malicious viz::CompositorFrame containing a viz::TransferableResource.
  3. Populate the ycbcr_info metadata field of the TransferableResource.
  4. Set the underlying uint32_t fields (e.g., suggested_ycbcr_model, suggested_ycbcr_range, suggested_xchroma_offset, suggested_ychroma_offset) to extremely large values (e.g., 0xFFFFFFFF) that do not correspond to valid Vulkan enums.
  5. Submit the CompositorFrame to the Viz compositor in the GPU process via the standard Mojo IPC channel.
  6. The GPU process will deserialize the frame, pass the malicious enums to the Vulkan driver, and trigger an out-of-bounds memory access, which the attacker can shape to achieve remote code execution in the GPU process.

Suggested Fix

Implement strict validation for all fields in gpu::VulkanYCbCrInfo when they cross the IPC boundary.

Modify StructTraits<gpu::mojom::VulkanYCbCrInfoDataView, gpu::VulkanYCbCrInfo>::Read in gpu/ipc/common/vulkan_ycbcr_info_mojom_traits.h to verify that each uint32_t value corresponds to a valid and supported Vulkan enum constant (e.g., checking against the maximum valid enum values for VkSamplerYcbcrModelConversion, VkSamplerYcbcrRange, etc.). If any value is out of bounds, the Read function should return false to reject the IPC message and terminate the misbehaving renderer.

Evaluated with Chrome root at commit: 0eb4855bda702feaaa8b899336664f97e3df88b8

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. Please feel free to reach out to me if you have concerns or feedback.

View on issue tracker
On This Page