High watch CVSS 8.3 chrome OOB 📄 Reporter bug report 🔧 Commit mapped

Overview

High
Severity
8.3
CVSS
No
Exploited ITW
Fixed
Fix Status
ImpactHeap buffer overflow in ANGLE
DescriptionHeap buffer overflow in ANGLE
ComponentANGLE
Sub-componentGL
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.
Tracker497928952
Fix commitc0c3b52cec94 (angle/angle) +88/-16
CWECWE-122 (Heap buffer overflow)
CVSS vectorCVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H
CISA KEVNot listed
CreditedNathaniel Oh (@calysteon)
Reported2026-03-30 · bounty $2000 (per vendor advisory)
Fix landed2026-04-07 (public git)
Disclosed2026-05-12
Patch gap35 days — fix public in source before the advisory

Background

Streaming client attributes
ANGLE’s GL backend copies vertex-attribute data held in client memory into a GPU buffer before a draw, sizing that buffer from the number of vertices/instances to be drawn.
`shiftInstancedArrayDataWithOffset` workaround
a driver workaround (mainly Intel on macOS) that, for drawArraysInstanced with first > 0, shifts instanced attribute data by the first offset, increasing the vertex count that must be laid out in the destination buffer.
`ComputeVertexBindingElementCount`
computes how many attribute elements must be streamed for a binding given its divisor, vertex count and instance count.
`adjustedDivisor`
the per-binding instance divisor after view adjustment; > 0 marks an instanced attribute, which is what the workaround rewrites.

Root Cause Analysis

VertexArrayGL::computeStreamingAttributeSizes sized the streaming buffer purely from ComputeVertexBindingElementCount(adjustedDivisor, indexRange.vertexCount(), instanceCount) and had no knowledge of the shiftInstancedArrayDataWithOffset workaround, so when the workaround was active it under-allocated: the destination needs room for the shifted layout (instanceCount + indexRange.start() + adjustedDivisor - 1) / adjustedDivisor elements, which is larger. In VertexArrayGL::streamAttributes the workaround then increased streamedVertexCount to that shifted value, and the slow-path copy loop iterated vertexIdx < streamedVertexCount to read from the source client memory — but the client buffer only holds the original instance count, so the loop both over-read the source and wrote past the under-allocated destination (the heap-buffer-overflow the advisory reports).

The fix threads an applyExtraOffsetWorkaroundForInstancedAttributes flag into computeStreamingAttributeSizes so the buffer is allocated at the shifted size, captures originalStreamedVertexCount before the workaround inflates the count, and changes the slow-path copy loop bound to originalStreamedVertexCount so only data that actually exists in the source is read. The destination layout still honors the increased streamedVertexCount for correct attribute spacing, so both the over-read and the over-write are eliminated.

Key insight
The sizing routine and the source-read loop used two different, inconsistent vertex counts: the allocation ignored the offset workaround while the copy used the inflated count, so the fix makes allocation workaround-aware and caps the source copy at originalStreamedVertexCount.

Attack Path

  1. Enable the vulnerable path On a configuration where Feature::ShiftInstancedArrayDataWithOffset is active (Intel/macOS, or forced), use an instanced attribute sourced from client memory with a divisor > 0.
  2. Issue an offset instanced draw Call glDrawArraysInstancedANGLE with first > 0 (the regression test uses first = 100, instanceCount = 1024) and a source stride different from the dest stride to force the slow copy path.
  3. Under-allocate the destination computeStreamingAttributeSizes sizes the buffer for the original count while the workaround inflates streamedVertexCount, leaving the destination too small.
  4. Overflow during copy The slow-path loop reads streamedVertexCount elements from the client source (past its end) and writes them into the undersized GPU staging buffer, producing a heap-buffer-overflow in the GPU process (inferred: controlled read/write primitive).

Impact Assessment

A WebGL page can trigger a heap buffer overflow in the GPU process by issuing an offset instanced draw with client-side instanced attributes while the workaround is enabled, giving an out-of-bounds read of adjacent heap and an out-of-bounds write into the staging buffer. The advisory rates this high severity (heap buffer overflow in ANGLE); any escalation to memory corruption primitives or code execution is (inferred) and not demonstrated by the diff, and no in-the-wild status is stated. Precondition: the Intel/macOS-style shiftInstancedArrayDataWithOffset workaround must be in effect.

Changed Functions

FunctionChangeNotes
VertexAttributeShiftInstancedArrayDataWithOffsetTest
src/tests/gl_tests/VertexAttributeTest.cpp
modified

Files Changed

  • src/libANGLE/renderer/gl/VertexArrayGL.cpp
  • src/libANGLE/renderer/gl/VertexArrayGL.h
  • src/tests/gl_tests/VertexAttributeTest.cpp

Audit Directions

  • Allocation vs. copy count mismatch
    Flag any streaming/staging routine where the size computation and the copy loop derive their element counts independently; they must use the same adjusted value.
  • Workaround-aware sizing
    When a driver workaround rewrites counts, strides or layout at draw time, verify every buffer sized earlier in the pipeline was told about that workaround.
  • Source vs. destination bounds
    Audit copy loops that reuse one count for both reading client memory and writing device memory; source reads must be bounded by the source’s real element count, independent of destination layout inflation.
From c0c3b52cec94593157bea7a5ecd9e1ab7b2ce802 Mon Sep 17 00:00:00 2001
From: Shrek Shao <shrekshao@google.com>
Date: Thu, 02 Apr 2026 13:05:19 -0700
Subject: [PATCH] GL: Fix heap-buffer-overflow in streamAttributes

When the shiftInstancedArrayDataWithOffset workaround is
enabled (primarily for Intel drivers on macOS), the number
of vertices to stream is increased to account for the first
parameter in drawArraysInstanced.

However, computeStreamingAttributeSizes was not aware of this
workaround, leading to an under-allocation of the streaming
buffer. Additionally, the copy loop in streamAttributes used
the increased vertex count to read from the source client
memory.
This resulted in a heap-buffer-overflow because the source
buffer might only contain enough data for the original instance
count, and the destination buffer was also too small for the
shifted layout.

This CL:
1. Updates computeStreamingAttributeSizes to accept an
applyExtraOffsetWorkaroundForInstancedAttributes flag and
correctly calculate the required buffer size when the
workaround is active.
2. Updates streamAttributes to only copy the original number
of vertices from the source memory in both fast and slow paths.
3. Ensures the destination buffer layout still respects the
increased vertex count for correct attribute spacing as required
by the workaround.
4. Adds a regression test
ShiftInstancedArrayDataWithOffsetSlowPath in
VertexAttributeTest.cpp that triggers the workaround
and the slow path copy loop.

Bug: b/497928952
Change-Id: I4b59ceec7cf9fc301eacb5b22faa4a3b2c2c863d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/7728161
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Shrek Shao <shrekshao@google.com>
Auto-Submit: Shrek Shao <shrekshao@google.com>
---

diff --git a/src/libANGLE/renderer/gl/VertexArrayGL.cpp b/src/libANGLE/renderer/gl/VertexArrayGL.cpp
index 489cbff..f4774a5 100644
--- a/src/libANGLE/renderer/gl/VertexArrayGL.cpp
+++ b/src/libANGLE/renderer/gl/VertexArrayGL.cpp
@@ -367,11 +367,13 @@
     return angle::Result::Continue;
 }
 
-void VertexArrayGL::computeStreamingAttributeSizes(const gl::AttributesMask &attribsToStream,
-                                                   GLsizei instanceCount,
-                                                   const gl::IndexRange &indexRange,
-                                                   size_t *outStreamingDataSize,
-                                                   size_t *outMaxAttributeDataSize) const
+void VertexArrayGL::computeStreamingAttributeSizes(
+    const gl::AttributesMask &attribsToStream,
+    GLsizei instanceCount,
+    const gl::IndexRange &indexRange,
+    size_t *outStreamingDataSize,
+    size_t *outMaxAttributeDataSize,
+    bool applyExtraOffsetWorkaroundForInstancedAttributes) const
 {
     *outStreamingDataSize    = 0;
     *outMaxAttributeDataSize = 0;
@@ -391,9 +393,14 @@
         // the attribute with the largest data size.
         size_t typeSize        = ComputeVertexAttributeTypeSize(attrib);
         GLuint adjustedDivisor = GetAdjustedDivisor(mAppliedNumViews, binding.getDivisor());
-        *outStreamingDataSize +=
-            typeSize * ComputeVertexBindingElementCount(adjustedDivisor, indexRange.vertexCount(),
-                                                        instanceCount);
+        size_t streamedVertexCount = ComputeVertexBindingElementCount(
+            adjustedDivisor, indexRange.vertexCount(), instanceCount);
+        if (applyExtraOffsetWorkaroundForInstancedAttributes && adjustedDivisor > 0)
+        {
+            streamedVertexCount =
+                (instanceCount + indexRange.start() + adjustedDivisor - 1u) / adjustedDivisor;
+        }
+        *outStreamingDataSize += typeSize * streamedVertexCount;
         *outMaxAttributeDataSize = std::max(*outMaxAttributeDataSize, typeSize);
     }
 }
@@ -413,7 +420,8 @@
     size_t maxAttributeDataSize = 0;
 
     computeStreamingAttributeSizes(attribsToStream, instanceCount, indexRange, &streamingDataSize,
-                                   &maxAttributeDataSize);
+                                   &maxAttributeDataSize,
+                                   applyExtraOffsetWorkaroundForInstancedAttributes);
 
     if (streamingDataSize == 0)
     {
@@ -468,6 +476,7 @@
             // shiftInstancedArrayDataWithOffset workaround, otherwise it's const
             size_t streamedVertexCount = ComputeVertexBindingElementCount(
                 adjustedDivisor, indexRange.vertexCount(), instanceCount);
+            const size_t originalStreamedVertexCount = streamedVertexCount;
 
             const size_t sourceStride = ComputeVertexAttributeStride(attrib, binding);
             const size_t destStride   = ComputeVertexAttributeTypeSize(attrib);
@@ -491,7 +500,6 @@
 
             if (applyExtraOffsetWorkaroundForInstancedAttributes && adjustedDivisor > 0)
             {
-                const size_t originalStreamedVertexCount = streamedVertexCount;
                 streamedVertexCount =
                     (instanceCount + indexRange.start() + adjustedDivisor - 1u) / adjustedDivisor;
 
@@ -545,7 +553,7 @@
             }
             else
             {
-                for (size_t vertexIdx = 0; vertexIdx < streamedVertexCount; vertexIdx++)
+                for (size_t vertexIdx = 0; vertexIdx < originalStreamedVertexCount; vertexIdx++)
                 {
                     uint8_t *out = bufferPointer + curBufferOffset + (destStride * vertexIdx);
                     const uint8_t *in =
diff --git a/src/libANGLE/renderer/gl/VertexArrayGL.h b/src/libANGLE/renderer/gl/VertexArrayGL.h
index 2b08576..b018e80 100644
--- a/src/libANGLE/renderer/gl/VertexArrayGL.h
+++ b/src/libANGLE/renderer/gl/VertexArrayGL.h
@@ -91,11 +91,13 @@
 
     // Returns the amount of space needed to stream all attributes that need streaming
     // and the data size of the largest attribute
-    void computeStreamingAttributeSizes(const gl::AttributesMask &attribsToStream,
-                                        GLsizei instanceCount,
-                                        const gl::IndexRange &indexRange,
-                                        size_t *outStreamingDataSize,
-                                        size_t *outMaxAttributeDataSize) const;
+    void computeStreamingAttributeSizes(
+        const gl::AttributesMask &attribsToStream,
+        GLsizei instanceCount,
+        const gl::IndexRange &indexRange,
+        size_t *outStreamingDataSize,
+        size_t *outMaxAttributeDataSize,
+        bool applyExtraOffsetWorkaroundForInstancedAttributes) const;
 
     // Stream attributes that have client data
     angle::Result streamAttributes(const gl::Context *context,
diff --git a/src/tests/gl_tests/VertexAttributeTest.cpp b/src/tests/gl_tests/VertexAttributeTest.cpp
index 8d84081..1c78745 100644
--- a/src/tests/gl_tests/VertexAttributeTest.cpp
+++ b/src/tests/gl_tests/VertexAttributeTest.cpp
@@ -5759,6 +5759,68 @@
 #    define EMULATED_VAO_CONFIGS
 #endif
 
+class VertexAttributeShiftInstancedArrayDataWithOffsetTest : public VertexAttributeTest
+{};
+
+// Regression test (crbug.com/497928952) for heap-buffer-overflow in streamAttributes() when
+// shiftInstancedArrayDataWithOffset workaround is enabled.
+TEST_P(VertexAttributeShiftInstancedArrayDataWithOffsetTest,
+       ShiftInstancedArrayDataWithOffsetSlowPath)
+{
+    // The workaround is specifically for Mac Intel, but we can enable it for this test.
+    // It is only triggered for drawArraysInstanced with first > 0.
+    // The slow path is triggered when sourceStride != destStride.
+    ANGLE_SKIP_TEST_IF(!IsGLExtensionEnabled("GL_ANGLE_instanced_arrays") &&
+                       getClientMajorVersion() < 3);
+
+    constexpr char kVS[] = R"(attribute vec4 position;
+attribute vec4 instance;
+varying vec4 color;
+void main() {
+    gl_Position = position + instance * 0.001;
+    color = vec4(1, 0, 0, 1);
+})";
+    constexpr char kFS[] = R"(varying lowp vec4 color;
+void main() {
+    gl_FragColor = color;
+})";
+
+    ANGLE_GL_PROGRAM(program, kVS, kFS);
+    glUseProgram(program);
+    GLint posLoc  = glGetAttribLocation(program, "position");
+    GLint instLoc = glGetAttribLocation(program, "instance");
+
+    auto quadVertices = GetQuadVertices();
+    GLBuffer posBuf;
+    glBindBuffer(GL_ARRAY_BUFFER, posBuf);
+    glBufferData(GL_ARRAY_BUFFER, quadVertices.size() * sizeof(Vector3), quadVertices.data(),
+                 GL_STATIC_DRAW);
+    glEnableVertexAttribArray(posLoc);
+    glVertexAttribPointer(posLoc, 3, GL_FLOAT, GL_FALSE, 0, nullptr);
+
+    const int instanceCount = 1024;
+    const int srcStride     = 20;  // 20 bytes stride for vec4 (16 bytes) forces slow path
+    std::vector<uint8_t> instData(instanceCount * srcStride, 0);
+    GLBuffer instBuf;
+    glBindBuffer(GL_ARRAY_BUFFER, instBuf);
+    glBufferData(GL_ARRAY_BUFFER, instData.size(), instData.data(), GL_STATIC_DRAW);
+    glEnableVertexAttribArray(instLoc);
+    glVertexAttribPointer(instLoc, 4, GL_FLOAT, GL_FALSE, srcStride, nullptr);
+    glVertexAttribDivisorANGLE(instLoc, 1);
+
+    const int first = 100;
Loading diff…

Regression Test / PoC

shipped with the fix
diff --git a/src/tests/gl_tests/VertexAttributeTest.cpp b/src/tests/gl_tests/VertexAttributeTest.cpp
index 8d84081..1c78745 100644
--- a/src/tests/gl_tests/VertexAttributeTest.cpp
+++ b/src/tests/gl_tests/VertexAttributeTest.cpp
@@ -5759,6 +5759,68 @@
 #    define EMULATED_VAO_CONFIGS
 #endif
 
+class VertexAttributeShiftInstancedArrayDataWithOffsetTest : public VertexAttributeTest
+{};
+
+// Regression test (crbug.com/497928952) for heap-buffer-overflow in streamAttributes() when
+// shiftInstancedArrayDataWithOffset workaround is enabled.
+TEST_P(VertexAttributeShiftInstancedArrayDataWithOffsetTest,
+       ShiftInstancedArrayDataWithOffsetSlowPath)
+{
+    // The workaround is specifically for Mac Intel, but we can enable it for this test.
+    // It is only triggered for drawArraysInstanced with first > 0.
+    // The slow path is triggered when sourceStride != destStride.
+    ANGLE_SKIP_TEST_IF(!IsGLExtensionEnabled("GL_ANGLE_instanced_arrays") &&
+                       getClientMajorVersion() < 3);
+
+    constexpr char kVS[] = R"(attribute vec4 position;
+attribute vec4 instance;
+varying vec4 color;
+void main() {
+    gl_Position = position + instance * 0.001;
+    color = vec4(1, 0, 0, 1);
+})";
+    constexpr char kFS[] = R"(varying lowp vec4 color;
+void main() {
+    gl_FragColor = color;
+})";
+
+    ANGLE_GL_PROGRAM(program, kVS, kFS);
+    glUseProgram(program);
+    GLint posLoc  = glGetAttribLocation(program, "position");
+    GLint instLoc = glGetAttribLocation(program, "instance");
+
+    auto quadVertices = GetQuadVertices();
+    GLBuffer posBuf;
+    glBindBuffer(GL_ARRAY_BUFFER, posBuf);
+    glBufferData(GL_ARRAY_BUFFER, quadVertices.size() * sizeof(Vector3), quadVertices.data(),
+                 GL_STATIC_DRAW);
+    glEnableVertexAttribArray(posLoc);
+    glVertexAttribPointer(posLoc, 3, GL_FLOAT, GL_FALSE, 0, nullptr);
+
+    const int instanceCount = 1024;
+    const int srcStride     = 20;  // 20 bytes stride for vec4 (16 bytes) forces slow path
+    std::vector<uint8_t> instData(instanceCount * srcStride, 0);
+    GLBuffer instBuf;
+    glBindBuffer(GL_ARRAY_BUFFER, instBuf);
+    glBufferData(GL_ARRAY_BUFFER, instData.size(), instData.data(), GL_STATIC_DRAW);
+    glEnableVertexAttribArray(instLoc);
+    glVertexAttribPointer(instLoc, 4, GL_FLOAT, GL_FALSE, srcStride, nullptr);
+    glVertexAttribDivisorANGLE(instLoc, 1);
+
+    const int first = 100;
+    // This will trigger the workaround and the overflow if the fix is not present.
+    glDrawArraysInstancedANGLE(GL_TRIANGLES, first, 6, instanceCount);
+    EXPECT_GL_NO_ERROR();
+}
+
+ANGLE_INSTANTIATE_TEST_ES2_AND_ES3_AND(
+    VertexAttributeShiftInstancedArrayDataWithOffsetTest,
+    ES2_OPENGL().enable(Feature::ShiftInstancedArrayDataWithOffset),
+    ES2_OPENGLES().enable(Feature::ShiftInstancedArrayDataWithOffset),
+    ES3_OPENGL().enable(Feature::ShiftInstancedArrayDataWithOffset),
+    ES3_OPENGLES().enable(Feature::ShiftInstancedArrayDataWithOffset));
+
 ANGLE_INSTANTIATE_TEST_ES2_AND_ES3_AND(
     VertexAttributeTest,
     ES2_VULKAN().enable(Feature::ForceFallbackFormat),
Loading diff…

Original Bug Report

reported by ca...@gmail.com

Heap-buffer-overflow in VertexArrayGL::streamAttributes via shiftInstancedArrayDataWithOffset

Steps to reproduce the problem

ASAN_OPTIONS=detect_leaks=0:halt_on_error=1:print_stacktrace=1 \
out/asan/chrome \
  --no-sandbox \
  --headless=new \
  --use-angle=gl \
  --ozone-platform=headless \
  --no-first-run \
  --disable-background-networking \
  --disable-sync \
  --disable-extensions \
  --ignore-gpu-blocklist \
  --enable-angle-features=shiftInstancedArrayDataWithOffset \
  --virtual-time-budget=20000 \
  poc.html

Problem Description

Summary

VertexArrayGL::streamAttributes() in ANGLE’s GL backend allocates a streaming vertex buffer based on ComputeVertexBindingElementCount(), then the shiftInstancedArrayDataWithOffset workaround increases streamedVertexCount after allocation. The slow-path memcpy loop writes past the buffer end. This is a heap-buffer-overflow in the GPU process, reachable from WebGL via drawArraysInstanced with first > 0.

  • File: third_party/angle/src/libANGLE/renderer/gl/VertexArrayGL.cpp
  • Bug lines: 492-496 (count increased), 548-554 (writes with increased count)
  • Process: GPU process
  • Tested: Chromium 148.0.7762.0 (commit 371e35b061)
  • Platform: macOS Intel (non-Haswell) by default; reproducible on any platform with --enable-angle-features=shiftInstancedArrayDataWithOffset

Root Cause

Line 415: computeStreamingAttributeSizes() computes streamingDataSize using the original vertex count from ComputeVertexBindingElementCount().

Line 438: Buffer allocated with original size: bufferData(GL_ARRAY_BUFFER, requiredBufferSize, ...).

Lines 495-496: Workaround increases the vertex count:

streamedVertexCount = (instanceCount + indexRange.start() + adjustedDivisor - 1u) / adjustedDivisor;

Lines 548-554: Slow-path copy loop uses the increased count:

for (size_t vertexIdx = 0; vertexIdx &lt; streamedVertexCount; vertexIdx++) {
    uint8_t *out = bufferPointer + curBufferOffset + (destStride * vertexIdx);
    const uint8_t *in = inputPointer + sourceStride * (vertexIdx + firstIndexForSeparateCopy);
    memcpy(out, in, destStride);
}

With first=100, instanceCount=1024, divisor=1: original count = 1024, new count = 1124. Buffer sized for 1024 vertices, loop writes 1124. Overflow = 100 * destStride bytes.

The slow path is taken when sourceStride != destStride (e.g., vertex attribute with stride=20 for vec4 which packs to 16).

Suggested Fix

In streamAttributes(), after the workaround modifies streamedVertexCount at line 495-496, recompute batchMemcpySize and ensure the buffer allocation at line 438 accounts for the maximum possible vertex count.

Summary

Heap-buffer-overflow in VertexArrayGL::streamAttributes via shiftInstancedArrayDataWithOffset

Custom Questions

Type of crash:

GPU process crash

Crash state:

==500925==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7186c57fd230 at pc 0x631b84c7600b bp 0x7ffc2b03d690 sp 0x7ffc2b03ce50
READ of size 16 at 0x7186c57fd230 thread T0 (chrome)
    #0 0x631b84c7600a in __asan_memcpy (/home/calysteon/chromium/src/out/asan/chrome+0x196e900a) (BuildId: 330ba48cdf0bd5aa)
    #1 0x6ee6ba61f271 in rx::VertexArrayGL::streamAttributes(gl::Context const*, angle::BitSetT<16ul, unsigned long, unsigned long> const&, int, gl::IndexRange const&, bool) const third_party/angle/src/libANGLE/renderer/gl/VertexArrayGL.cpp:553:21
    #2 0x6ee6ba61beb5 in rx::VertexArrayGL::syncDrawState(gl::Context const*, angle::BitSetT<16ul, unsigned long, unsigned long> const&, int, int, gl::DrawElementsType, void const*, int, bool, void const**) const third_party/angle/src/libANGLE/renderer/gl/VertexArrayGL.cpp:264:27
    #3 0x6ee6ba61b6de in rx::VertexArrayGL::syncClientSideData(gl::Context const*, angle::BitSetT<16ul, unsigned long, unsigned long> const&, int, int, int) const third_party/angle/src/libANGLE/renderer/gl/VertexArrayGL.cpp:180:12
    #4 0x6ee6ba4e5453 in rx::ContextGL::drawArraysInstanced(gl::Context const*, gl::PrimitiveMode, int, int, int) third_party/angle/src/libANGLE/renderer/gl/ContextGL.cpp:266:26
    #5 0x6ee6b9f7c6d8 in gl::Context::drawArraysInstanced(gl::PrimitiveMode, int, int, int) third_party/angle/src/libANGLE/Context.cpp:2961:26
    #6 0x6ee6b9779072 in GL_DrawArraysInstanced third_party/angle/src/libGLESv2/entry_points_gles_3_0_autogen.cpp:1132:22
    #7 0x631bad5b541d in gpu::gles2::GLES2DecoderImpl::HandleDrawArraysInstancedANGLE(unsigned int, void const volatile*) gpu/command_buffer/service/<gles2_cmd_decoder.cc:9429>:18
    #8 0x631bad5fbd19 in gpu::error::Error gpu::gles2::GLES2DecoderImpl::DoCommandsImpl<false>(unsigned int, void const volatile*, int, int*) gpu/command_buffer/service/<gles2_cmd_decoder.cc:4766>:18
    #9 0x631b93ed348d in gpu::CommandBufferService::Flush(int, gpu::AsyncAPIInterface*) gpu/command_buffer/service/<command_buffer_service.cc:267>:35
    #10 0x631bad49be45 in gpu::CommandBufferStub::OnAsyncFlush(int, unsigned int, std::__Cr::vector<gpu::SyncToken, std::__Cr::allocator<gpu::SyncToken>> const&) gpu/ipc/service/<command_buffer_stub.cc:504>:22
    #11 0x631bad49ae36 in gpu::CommandBufferStub::ExecuteDeferredRequest(gpu::mojom::DeferredCommandBufferRequestParams&, gpu::FenceSyncReleaseDelegate*) gpu/ipc/service/<command_buffer_stub.cc:173>:7
    #12 0x631bad4c5a1b in gpu::GpuChannel::ExecuteDeferredRequest(mojo::StructPtr<gpu::mojom::DeferredRequestParams>, gpu::FenceSyncReleaseDelegate*) gpu/ipc/service/<gpu_channel.cc:833>:13
    #13 0x631bad4d3f17 in void base::internal::DecayedFunctorTraits<void (gpu::GpuChannel::*)(mojo::StructPtr<gpu::mojom::DeferredRequestParams>, gpu::FenceSyncReleaseDelegate*), base::WeakPtr<gpu::GpuChannel>&&, mojo::StructPtr<gpu::mojom::DeferredRequestParams>&&>::Invoke<void (gpu::GpuChannel::*)(mojo::StructPtr<gpu::mojom::DeferredRequestParams>, gpu::FenceSyncReleaseDelegate*), base::WeakPtr<gpu::GpuChannel> const&, mojo::StructPtr<gpu::mojom::DeferredRequestParams>, gpu::FenceSyncReleaseDelegate*>(void (gpu::GpuChannel::*)(mojo::StructPtr<gpu::mojom::DeferredRequestParams>, gpu::FenceSyncReleaseDelegate*), base::WeakPtr<gpu::GpuChannel> const&, mojo::StructPtr<gpu::mojom::DeferredRequestParams>&&, gpu::FenceSyncReleaseDelegate*&&) base/functional/bind_internal.h:740:12
    #14 0x631bad4d3cf9 in base::internal::Invoker<base::internal::FunctorTraits<void (gpu::GpuChannel::*&&)(mojo::StructPtr<gpu::mojom::DeferredRequestParams>, gpu::FenceSyncReleaseDelegate*), base::WeakPtr<gpu::GpuChannel>&&, mojo::StructPtr<gpu::mojom::DeferredRequestParams>&&>, base::internal::BindState<true, true, false, void (gpu::GpuChannel::*)(mojo::StructPtr<gpu::mojom::DeferredRequestParams>, gpu::FenceSyncReleaseDelegate*), base::WeakPtr<gpu::GpuChannel>, mojo::StructPtr<gpu::mojom::DeferredRequestParams>>, void (gpu::FenceSyncReleaseDelegate*)>::RunOnce(base::internal::BindStateBase*, gpu::FenceSyncReleaseDelegate*) base/functional/bind_internal.h:956:5
    #15 0x631b93f20bb8 in base::OnceCallback<void (gpu::FenceSyncReleaseDelegate*)>::Run(gpu::FenceSyncReleaseDelegate*) && base/functional/callback.h:155:12
    #16 0x631b93f2092a in void base::internal::Invoker<base::internal::FunctorTraits<base::OnceCallback<void (gpu::FenceSyncReleaseDelegate*)>&&, gpu::FenceSyncReleaseDelegate*>, base::internal::BindState<false, true, true, base::OnceCallback<void (gpu::FenceSyncReleaseDelegate*)>, base::internal::UnretainedWrapper<gpu::FenceSyncReleaseDelegate, base::unretained_traits::MayNotDangle, (partition_alloc::internal::RawPtrTraits)0>>, void ()>::RunImpl<base::OnceCallback<void (gpu::FenceSyncReleaseDelegate*)>, std::__Cr::tuple<base::internal::UnretainedWrapper<gpu::FenceSyncReleaseDelegate, base::unretained_traits::MayNotDangle, (partition_alloc::internal::RawPtrTraits)0>>, 0ul>(base::OnceCallback<void (gpu::FenceSyncReleaseDelegate*)>&&, std::__Cr::tuple<base::internal::UnretainedWrapper<gpu::FenceSyncReleaseDelegate, base::unretained_traits::MayNotDangle, (partition_alloc::internal::RawPtrTraits)0>>&&, std::__Cr::integer_sequence<unsigned long, 0ul>) base/functional/bind_internal.h:815:49
    #17 0x631b85572945 in base::OnceCallback<void ()>::Run() && base/functional/callback.h:155:12
    #18 0x631b93eee378 in gpu::Scheduler::ExecuteSequence(base::IdType<gpu::SyncPointOrderData, unsigned int, 0u, 1u>) gpu/command_buffer/service/<scheduler.cc:707>:29
    #19 0x631b93eeba79 in gpu::Scheduler::RunNextTask() gpu/command_buffer/service/<scheduler.cc:625>:3
    #20 0x631b93ef0af1 in base::internal::Invoker<base::internal::FunctorTraits<void (gpu::Scheduler::*&&)(), gpu::Scheduler*>, base::internal::BindState<true, true, false, void (gpu::Scheduler::*)(), base::internal::UnretainedWrapper<gpu::Scheduler, base::unretained_traits::MayNotDangle, (partition_alloc::internal::RawPtrTraits)0>>, void ()>::RunOnce(base::internal::BindStateBase*) base/functional/bind_internal.h:740:12
    #21 0x631b85572945 in base::OnceCallback<void ()>::Run() && base/functional/callback.h:155:12
    #22 0x631ba309a7d7 in base::TaskAnnotator::RunTaskImpl(base::PendingTask&) base/task/common/<task_annotator.cc:229>:34
    #23 0x631ba314a045 in base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWorkImpl(base::LazyNow*) base/task/common/task_annotator.h:112:5
    #24 0x631ba31483ed in base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWork() base/task/sequence_manager/<thread_controller_with_message_pump_impl.cc:340>:40
    #25 0x631ba2f19d33 in base::MessagePumpDefault::Run(base::MessagePump::Delegate*) base/message_loop/<message_pump_default.cc:42>:55
    #26 0x631ba314c442 in base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::Run(bool, base::TimeDelta) base/task/sequence_manager/<thread_controller_with_message_pump_impl.cc:644>:12
    #27 0x631ba2ffc654 in base::RunLoop::Run(base::Location const&) base/<run_loop.cc:135>:14
    #28 0x631bafca9c53 in content::GpuMain(content::MainFunctionParams) content/gpu/<gpu_main.cc:484>:14
    #29 0x631b9e44968a in content::RunZygote(content::ContentMainDelegate*) content/app/<content_main_runner_impl.cc:664>:14
    #30 0x631b9e44ad86 in content::RunOtherNamedProcessTypeMain(std::__Cr::basic_string<char, std::__Cr::char_traits<char>, std::__Cr::allocator<char>> const&, content::MainFunctionParams, content::ContentMainDelegate*) content/app/<content_main_runner_impl.cc:771>:12
    #31 0x631b9e44e0cc in content::ContentMainRunnerImpl::Run() content/app/<content_main_runner_impl.cc:1152>:10
    #32 0x631b9e447241 in content::RunContentProcess(content::ContentMainParams, content::ContentMainRunner*) content/app/<content_main.cc:358>:36
    #33 0x631b9e44783c in content::ContentMain(content::ContentMainParams) content/app/<content_main.cc:371>:10
    #34 0x631b84cb2b38 in ChromeMain chrome/app/<chrome_main.cc:191>:12
    #35 0x72e6c722a1c9 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
    #36 0x72e6c722a28a in __libc_start_main csu/../csu/libc-start.c:360:3

SUMMARY: AddressSanitizer: heap-buffer-overflow (/home/calysteon/chromium/src/out/asan/chrome+0x196e900a) (BuildId: 330ba48cdf0bd5aa) in __asan_memcpy

Reporter credit:

Nathaniel Oh (@calysteon)

Additional Data

Category: Security
Chrome Channel: Dev
Regression: N/A \

View on issue tracker