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 without the Chrome Security team.

Overview: A potential integer overflow in SkTDStorage::bytes() allows GrAAConvexTessellator::extractFromPath to allocate an undersized buffer while establishing a massive capacity. By crafting an SkPath heavily populated with degenerate edges, an attacker can bypass immediate crashes and perform a precise out-of-bounds heap write. This could potentially be leveraged for remote code execution in the GPU process.

Affected files:

• third_party/skia/src/gpu/ganesh/geometry/GrAAConvexTessellator.cpp
• third_party/skia/include/private/base/SkTDArray.h
• third_party/skia/src/base/SkTDArray.cpp
• third_party/skia/src/gpu/ganesh/geometry/GrAAConvexTessellator.h

Estimated timestamp from git blame: 2022-11-01

Background

Skia’s Ganesh rendering engine uses GrAAConvexTessellator to generate anti-aliased meshes for convex paths. When processing a path, GrAAConvexTessellator::extractFromPath attempts to pre-allocate memory for the generated vertices by calling this->reservePts(5 * path.countPoints()).

Root Cause

The reservePts method invokes reserve() on internal SkTDArray instances (like fPts, which stores SkPoint). Inside SkTDStorage::reserve(int newCapacity), the required allocation size in bytes is calculated via the bytes() helper:

// third_party/skia/include/private/base/SkTDArray.h
size_t bytes(int n) const { return SkToSizeT(n * fSizeOfT); }

Because both n and fSizeOfT are signed 32-bit integers, their product can overflow before being cast to size_t. For an array of SkPoint elements (fSizeOfT == 8), if expandedReserve reaches a massive value like 1,073,741,830, the multiplication 1,073,741,830 * 8 overflows to the truncated 32-bit value 48.

Consequently, sk_realloc_throw allocates a tiny 48-byte buffer, but the array’s internal fCapacity is erroneously recorded as 1,073,741,830.

Bypassing the Immediate Crash

Typically, a massive, immediate loop writing to an undersized buffer would crash deterministically, turning this into a Denial of Service. However, extractFromPath iterates over the path using an SkPathEdgeIter and explicitly skips degenerate segments where all points are identical:

if (!SkPathPriv::AllPointsEq({e.fPts, 2})) {
    this->lineTo(m, e.fPts[1], kSharp_CurveState);
}

If the path is constructed almost entirely of degenerate edges, lineTo (and subsequently addPt) is never called. The fSize of the array remains 0. When the iteration finally encounters non-degenerate edges at the end of the path, addPt invokes fPts.append(). Because fSize < fCapacity remains true, append simply increments fSize without reallocating, returning pointers that eventually fall outside the 48-byte allocated heap buffer.

Potential Exploitation Steps

Note: Our tooling agent cannot run code, so these are suggested steps based on static code analysis.

1. Construct the Malicious Path: An attacker crafts an SkPath comprising roughly 171.8 million points (e.g., using ~57.3 million cubicTo verbs). This size results in an expandedReserve of 1,073,741,830.
2. Pad with Degenerate Edges: The first ~171.79 million points are structured as degenerate edges (where start, control, and end points are identical) to ensure AllPointsEq returns true and addPt is skipped.
3. Append Out-of-Bounds Payload: The final few points in the path are crafted with non-degenerate coordinates containing precise float payloads.
4. Deliver to GPU Process: To bypass the standard 16MB PaintOp limit, the 1.4GB serialized path is encapsulated within a Font Strike or Skottie Transfer Cache, which uses Shared Memory to transfer massive payloads directly to the GPU process.
5. Trigger Tessellation: When the GPU process deserializes and renders the path, the capacity overflows, allocating a 48-byte buffer. The degenerate edges are skipped, and the final payload points are written exactly out-of-bounds into adjacent PartitionAlloc heap structures, allowing the attacker to corrupt metadata or vtables.

(Note: extractFromPath also calls fIndices.reserve, which overflows to a negative signed integer. In release builds, SkTDStorage::reserve ignores negative capacity requests, rendering this secondary overflow a harmless no-op).

Suggested Fix

Refactor SkTDStorage::bytes to perform the multiplication safely in 64-bit space or check for overflow to prevent returning truncated allocation sizes:

size_t bytes(int n) const {
    return SkSafeMath::Mul(SkToSizeT(n), SkToSizeT(fSizeOfT));
}

Evaluated with Chrome root at commit: 096fc8fdbfacf2546485756d03f160a3d04fcc9b

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. And please feel free to reach out to me directly if you have concerns or feedback on the project.