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: An integer overflow in HarfBuzz’s VarData::get_size function can lead to an undersized buffer allocation when subsetting variable fonts. This result in a potential large out-of-bounds heap write during the serialization of variation data in the PrintCompositor utility process.

Affected files:

• third_party/harfbuzz/src/src/hb-ot-layout-common.hh

Estimated timestamp from git blame: 2019-10-16

Summary

A potential integer overflow exists in the VarData::get_size() function within HarfBuzz, which is used to calculate the required buffer size for serializing variation data during the subsetting of OpenType variable fonts (e.g., in GDEF, HVAR, or VVAR tables). The calculation itemCount * get_row_size() is performed using 32-bit unsigned arithmetic. If the product exceeds $2^{32}$, it wraps around, causing the HarfBuzz serialization context to allocate an undersized buffer. Subsequent writes to this buffer during the subsetting process can result in a massive out-of-bounds heap write.

Root Cause Analysis

In third_party/harfbuzz/src/src/hb-ot-layout-common.hh, the VarData::get_size() function calculates the size of the variation data sub-table:

unsigned int get_row_size () const
{ return (wordCount () + regionIndices.len) * (longWords () ? 2 : 1); }

size_t get_size () const
{ return min_size
       - regionIndices.min_size + regionIndices.get_size ()
       + itemCount * get_row_size (); }

Here, itemCount is an HBUINT16 (up to 65,535) and get_row_size() returns an unsigned int (up to ~196 KB). The multiplication itemCount * get_row_size() is performed as a 32-bit unsigned int. For a maliciously crafted font or an extremely large variation store, this product can exceed 0xFFFFFFFF, leading to an integer wrap-around.

During font subsetting, VarData::serialize() calls c->extend(this) (where c is an hb_serialize_context_t), which invokes get_size() to determine the allocation size. Because of the overflow, the context may allocate a buffer that is significantly smaller than required. The subsequent serialization loop in VarData::serialize() writes data using set_item_delta_fast(), which calculates write offsets without further bounds checks, resulting in an out-of-bounds write of potentially several gigabytes.

Reachability

This issue is reachable in the PrintCompositor utility process, which is responsible for converting web content into PDF format for printing. When a user prints a page containing a variable font, the PrintCompositor process uses Skia’s PDF backend, which in turn utilizes HarfBuzz’s subsetting functionality to embed a reduced version of the font in the PDF. An attacker could potentially trigger this by providing a crafted font via a compromised renderer or a web font on a malicious page and inducing a print operation (e.g., via window.print()).

Potential Steps to Reproduce

1. Construct a variable font with an ItemVariationStore containing many small VarData sub-tables (to pass initial font sanitization).
2. Use a subsetting plan that causes the HarfBuzz subsetter to merge these sub-tables into a single large VarData object (a common optimization in HarfBuzz).
3. Trigger a print or PDF export operation in Chrome that processes this font.
4. During the re-serialization of the subsetted font, the overflow in get_size() will occur, leading to heap corruption and a crash in the PrintCompositor process.

Note: These steps are based on a source code analysis; a functional proof-of-concept has not yet been developed.

Suggested Fix

Modify VarData::get_size() to perform the multiplication safely using hb_unsigned_mul_overflows() or by casting the operands to a 64-bit integer before multiplication, ensuring the result is checked against potential overflows before being used for allocation. Alternatively, validate the product within VarData::serialize() before calling c->extend().

Evaluated with Chrome root at commit: b3153093eb3c78c3e88ccf562bcbc20437a04b0e

Results so far have been promising, but there can be wrong deductions. Feel free to adjust as follows:

• If you are familiar with the severity guidelines, you may adjust the severity.
• If this is a false positive, and there’s no work to be done, please close as WAI.
• If there is work to do here but not a vulnerability, please change the issue type to Task/Bug/FR.

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.