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. Please see https://chromium.googlesource.com/chromium/src/+/main/docs/security/ai-generated-security-bugs-faq.md for more information.

Overview: A signed 16-bit integer overflow in FreeType’s tt_interpolate_deltas loop counter can bypass bounds checks when processing composite glyphs with 32,768 or more contours. This leads to a heap out-of-bounds read, supplying a manipulated endpoint to tt_delta_shift, which subsequently allows an attacker to perform a heap out-of-bounds write. This is reachable in Chromium via the sandboxed PrintCompositor process.

Affected files:

• third_party/freetype/src/src/truetype/ttgxvar.c
• third_party/freetype/src/src/truetype/ttgload.c
• third_party/freetype/src/include/freetype/ftimage.h

Estimated timestamp from git blame: 2015-05-31

Summary

A signed 16-bit integer overflow in FreeType’s tt_interpolate_deltas function leads to heap out-of-bounds (OOB) reads and writes. The function uses a signed FT_Short for its contour loop counter, while the total number of contours (n_contours) is an unsigned short. When a composite glyph contains 32,768 or more contours, the counter overflows to a negative value, bypassing the loop termination condition due to C integer promotion rules. This leads to an OOB read of an endpoint array, which is then used as an upper bound in a subsequent loop (tt_delta_shift), enabling a heap OOB write. This code path is reachable in Chromium’s sandboxed PrintCompositor process via malicious Skia serialized pictures.

Vulnerability Details

The vulnerability exists in third_party/freetype/src/src/truetype/ttgxvar.c within the tt_interpolate_deltas function:

FT_Short  contour;
...
contour = 0;
do {
  end_point = outline->contours[contour]; // OOB Read when contour < 0
  ...
  contour++;
} while ( contour < outline->n_contours ); // unsigned short n_contours

FT_Short is a signed 16-bit integer. FreeType limits the total number of contours (n_contours) to USHRT_MAX (65,535). If an attacker crafts a font with 32,768 or more contours, the contour variable increments until it reaches 32,767. On the next increment, it wraps around to -32,768.

Under C integer promotion rules, the comparison contour < outline->n_contours promotes both the signed short (-32,768) and the unsigned short (e.g., 32,768) to 32-bit signed ints. The comparison (int)-32,768 < (int)32,768 evaluates to true, and the loop erroneously continues with a negative index.

This results in an OOB read of outline->contours[-32768]. The value read becomes end_point. If the attacker has groomed the heap such that this memory location contains a large value, it can be passed to functions like tt_delta_shift:

// tt_delta_shift OOB write sink in ttgxvar.c
for ( p = ref + 1; p <= p2; p++ ) // p2 is the attacker-controlled end_point
{
  out_points[p].x += delta.x;
  out_points[p].y += delta.y;
}

Because tt_delta_shift lacks bounds checking against the pool buffer holding out_points, the loop will process points far past the end of the allocation. The attacker controls delta.x and delta.y via the gvar table, granting a powerful OOB addition primitive against adjacent heap structures.

Reachability in Chromium

This vulnerability is reachable via the PrintCompositor utility process, which renders page contents to PDF. An attacker who has compromised a renderer process can serialize an SkPicture object containing a font descriptor.

By manually setting the Skia font FactoryId in the serialized stream to SkSetFourByteTag('f','r','e','e') (SkTypeface_FreeType::FactoryId), the attacker bypasses Web Font (OTS) sanitization. The PrintCompositor process invokes SkPicture::MakeFromStream, which resolves the ID and calls SkTypeface_FreeType::MakeFromStream. This directly initializes the malicious font via FreeType (FT_Open_Face). When the SkPicture is rasterized, the vulnerable variation processing path is triggered.

Potential Exploitation Steps

Note: These are suggested steps based on static analysis; a working Proof-of-Concept has not been run.

1. Gain code execution within a sandboxed renderer process.
2. Construct a TrueType font containing a composite glyph with at least 32,768 contours. Include a gvar table with variation deltas for this glyph.
3. Serialize an SkPicture that references this font, manually setting the FactoryId in the binary stream to 'free'.
4. Groom the heap in the PrintCompositor process (e.g., via IPC spray) to place a large 16-bit value exactly 65,536 bytes before the anticipated outline->contours allocation.
5. Send the SkPicture to PrintCompositor via the mojom::PrintCompositor::CompositePage IPC interface.
6. The PrintCompositor deserializes the payload, triggers the OOB read to fetch the large endpoint, and then performs OOB writes (add primitive), corrupting adjacent heap objects (e.g., vtables) to hijack control flow.

Proposed Fix

In third_party/freetype/src/src/truetype/ttgxvar.c, update the type of the contour local variable in tt_interpolate_deltas to an FT_Int or an unsigned short so that it safely accommodates the maximum possible value of outline->n_contours without overflowing.

Evaluated with Chrome root at commit: 7353d249d9cacf9c7218e1d7b8a39cf39c72d646

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.