High watch CVSS 8.3 chrome OOB 🔧 Commit mapped

Overview

High
Severity
8.3
CVSS
No
Exploited ITW
Fixed
Fix Status
ImpactOut of bounds write in GPU
DescriptionOut of bounds write in GPU
ComponentGPU
Bug ClassOOB
Action tierwatch — corruption primitive but gated (uncommon) — not default-reachable
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.
Tracker562004351
Fix commit545222b904aa (chromium/src) +6/-0
CWECWE-787 (Out-of-bounds write)
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-09-15 (per vendor advisory)
Fix landed2026-09-17 (public git)
Disclosed2026-09-29
Patch gap12 days — fix public in source before the advisory

Background

Shared image backing
A GPU-service abstraction wrapping the actual storage for a shared image; ExternalVkImageBacking is the Vulkan-backed variant, produced by ExternalVkImageBackingFactory.
`GpuMemoryBuffer` (GMB)
A cross-process buffer whose type is described by gfx::GpuMemoryBufferType; a value of EMPTY_BUFFER means no client-provided buffer, whereas other types denote a buffer handed in by a (less-trusted) client.
`OzoneImageBacking`
The backing implementation intended to handle client-provided GMBs on non-Fuchsia platforms, i.e. the correct owner of that code path.
Fuchsia gating
The added check lives inside a platform #endif region, restricting client-GMB handling in this factory to Fuchsia only.

Root Cause Analysis

ExternalVkImageBackingFactory’s support/validation routine accepted requests to create an ExternalVkImageBacking from a client-provided GpuMemoryBuffer (a gmb_type other than gfx::GpuMemoryBufferType::EMPTY_BUFFER) on platforms other than Fuchsia, even though this path was, per the commit message, “not intended to be used” outside Fuchsia and should be served by OzoneImageBacking. Handling a client-supplied buffer through the Vulkan external-image path exercises size/format/stride handling that was not designed or hardened for arbitrary client GMBs on those platforms, and the advisory attributes an out-of-bounds write in the GPU process to this.

The fix adds an early if (gmb_type != gfx::GpuMemoryBufferType::EMPTY_BUFFER) { return false; } inside the non-Fuchsia region, so the factory reports it cannot create the backing and the request is rejected before any buffer-derived allocation or copy occurs. This tightens validation: creation from a client-provided GMB is now refused on all non-Fuchsia platforms rather than being attempted.

Key insight
The single mistake is that ExternalVkImageBackingFactory permitted creation of a Vulkan external-image backing from a client-provided GpuMemoryBuffer on platforms where that path was never meant to run; the fix rejects any non-EMPTY_BUFFER gmb_type outside Fuchsia so the untested code path can no longer be reached.

Attack Path

  1. Reach the shared-image factory From a compromised or malicious renderer/client, issue a shared-image creation request that selects the ExternalVkImageBacking path and supplies a client GpuMemoryBuffer (a non-EMPTY_BUFFER gmb_type). (inferred as to the exact client API)
  2. Bypass the intended owner On a non-Fuchsia platform, pre-patch the factory accepts the request instead of deferring the client GMB to OzoneImageBacking.
  3. Drive the unintended path The client-controlled buffer descriptors (dimensions/format/stride) flow into Vulkan external-image handling that assumes constraints only guaranteed elsewhere, producing an out-of-bounds write in the GPU process. (inferred mechanism; the diff shows only the added guard, not the sink)

Impact Assessment

An attacker able to issue GPU shared-image creation requests (typically from the renderer) could trigger an out-of-bounds write in the GPU process by forcing client-GMB creation through ExternalVkImageBackingFactory on a non-Fuchsia platform. The vendor advisory rates this high severity and does not report in-the-wild exploitation; NVD scores it CVSS 8.3. Escalation of the OOB write to code execution or a sandbox escape is not demonstrated by the patch (inferred).

Changed Functions

FunctionChangeNotes
if
gpu/command_buffer/service/shared_image/external_vk_image_backing_factory.cc
modified

Files Changed

  • gpu/command_buffer/service/shared_image/external_vk_image_backing_factory.cc

Audit Directions

  • Platform-gated code paths reachable off-platform
    Look for backing/factory logic guarded only by comments or assumptions (“not intended to be used”) rather than an explicit runtime rejection, especially where a different backing (e.g. Ozone) is the intended owner.
  • Client-provided buffer descriptors
    Audit every SharedImageBackingFactory that consumes a client GpuMemoryBuffer to confirm dimensions/format/stride are validated against the actual allocation before any read or write.
  • `gmb_type`/buffer-type discrimination
    Search for factory IsSupported/CanCreate checks that fail to distinguish EMPTY_BUFFER from client-supplied GMB types, which can silently admit externally controlled buffers into internal-only paths.
From 545222b904aa446dcb40a51fdca3568f0e922ddb Mon Sep 17 00:00:00 2001
From: kylechar <kylechar@chromium.org>
Date: Thu, 17 Sep 2026 08:35:24 -0700
Subject: [PATCH] Limit ExternalVkImageBacking usage

Don't allow creation of ExternalVkImageBacking for a client provided
buffer outside of Fuchsia. This functionality was not intended to be
used.

Bug: 562004351
Change-Id: If4b17f94dfde8fed1ed24f340cf13ef08cb7c7a8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/8415592
Reviewed-by: Vasiliy Telezhnikov <vasilyt@chromium.org>
Commit-Queue: Kyle Charbonneau <kylechar@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1699830}
---
diff --git a/gpu/command_buffer/service/shared_image/external_vk_image_backing_factory.cc b/gpu/command_buffer/service/shared_image/external_vk_image_backing_factory.cc
index 324a30e3..1ab6a8e2 100644
--- a/gpu/command_buffer/service/shared_image/external_vk_image_backing_factory.cc
+++ b/gpu/command_buffer/service/shared_image/external_vk_image_backing_factory.cc
@@ -118,6 +118,12 @@
       return false;
     }
   }
+
+  // Don't allow creating for a client provided GMB outside of Fuchsia. That is
+  // handled by OzoneImageBacking instead.
+  if (gmb_type != gfx::GpuMemoryBufferType::EMPTY_BUFFER) {
+    return false;
+  }
 #endif
 
   if (format.is_multi_plane()) {
Loading diff…