CVE-2026-102301
Overview
Background
- Shared image backing
- A GPU-service abstraction wrapping the actual storage for a shared image;
ExternalVkImageBackingis the Vulkan-backed variant, produced byExternalVkImageBackingFactory. - `GpuMemoryBuffer` (GMB)
- A cross-process buffer whose type is described by
gfx::GpuMemoryBufferType; a value ofEMPTY_BUFFERmeans 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
#endifregion, 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.
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
- Reach the shared-image factory
From a compromised or malicious renderer/client, issue a shared-image creation request that selects the
ExternalVkImageBackingpath and supplies a clientGpuMemoryBuffer(a non-EMPTY_BUFFERgmb_type). (inferred as to the exact client API) - Bypass the intended owner
On a non-Fuchsia platform, pre-patch the factory accepts the request instead of deferring the client GMB to
OzoneImageBacking. - 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
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
| Function | Change | Notes |
|---|---|---|
ifgpu/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-platformLook 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 descriptorsAudit every
SharedImageBackingFactorythat consumes a clientGpuMemoryBufferto confirm dimensions/format/stride are validated against the actual allocation before any read or write. - `gmb_type`/buffer-type discriminationSearch for factory
IsSupported/CanCreatechecks that fail to distinguishEMPTY_BUFFERfrom client-supplied GMB types, which can silently admit externally controlled buffers into internal-only paths.
Patch
From 545222b904aa446dcb40a51fdca3568f0e922ddb Mon Sep 17 00:00:00 2001 From: kylechar <[email protected]> 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 <[email protected]> Commit-Queue: Kyle Charbonneau <[email protected]> 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()) {