Project Fortify, an experimental security project, has identified the following potential security issue.

Overview: A negation overflow in HarfBuzz’s cursive attachment logic occurs when an attachment chain distance is exactly INT16_MIN (-32768). This bypasses truncation checks and leads to a massive out-of-bounds array access when the chain is reversed. On 32-bit platforms, this wraps to a predictable negative offset, potentially allowing reliable heap underflow writes and renderer RCE.

Affected files:

• third_party/harfbuzz-ng/src/src/OT/Layout/GPOS/CursivePosFormat1.hh

Estimated timestamp from git blame: 2025-11-03

Summary

A potential vulnerability exists in HarfBuzz’s OpenType Layout engine (third_party/harfbuzz-ng/src/src/OT/Layout/GPOS/CursivePosFormat1.hh). A negation overflow can corrupt a glyph’s attachment chain, leading to out-of-bounds (OOB) memory accesses.

Because HarfBuzz processes untrusted web fonts inside the renderer process, and the affected array (hb_glyph_position_t *pos) is a raw C-style pointer unprotected by MiraclePtr (BackupRefPtr), this bug can be weaponized. On 64-bit systems, it causes a deterministic crash (Denial of Service). On 32-bit systems (like Chrome on 32-bit Android), integer wrapping turns this into a reliable heap underflow write, providing a strong primitive for Remote Code Execution (RCE).

Root Cause Analysis

The vulnerability stems from the handling of the 16-bit signed integer attach_chain().

1. The Bypass: In CursivePosFormat1::apply, the distance between a parent and child glyph is calculated and stored. If a Left-to-Right layout attaches a parent at index 0 to a child at index 32768, the distance is 0 - 32768 = -32768. Because -32768 (INT16_MIN) perfectly fits into the signed 16-bit attach_chain() field, it survives the truncation guard check (pos[child].attach_chain() != (int) parent - (int) child) at line 234.
2. The Negation Overflow: When a subsequent Right-to-Left lookup forces HarfBuzz to reverse the attachment tree, it calls reverse_cursive_minor_offset(). At line 75, it attempts to invert the chain direction: pos[j].attach_chain() = -chain;. Since chain is -32768, -chain becomes 32768. Assigning 32768 to the int16_t field overflows the maximum positive value (32767), wrapping back to -32768.
3. The OOB Access: The chain is now corrupted. When the engine traverses this chain again, it calculates the next index at line 62: unsigned int j = (int) i + chain;. If i = 0 and chain = -32768, j becomes -32768, which casts to the unsigned integer 4294934528. This massive index is then used for recursive reads and writes, such as pos[j].attach_chain() = -chain.

Platform Specific Impact

• 64-bit Platforms: The array element size is 20 bytes. 4294934528 * 20 bytes results in an offset of approximately 85.8 GB. Accessing this address deterministically hits unmapped memory, crashing the renderer (DoS).
• 32-bit Platforms: The pointer arithmetic (4294934528 * 20) is constrained to 32 bits. Mathematically, 0xFFFF8000 * 0x14 wraps to 0xFFF60000. Interpreted as a signed 32-bit offset, this is exactly -655360 bytes. This creates a highly predictable 640 KB heap underflow.

Suggested Attacker Steps

(Note: These are potential steps based on static analysis, as our setup does not run live exploit code.)

1. Create a web page embedding a malicious OpenType font and a text string that generates a HarfBuzz buffer of at least 32,769 glyphs.
2. Groom the 32-bit renderer heap such that attacker-controlled data is placed exactly 640 KB before the target HarfBuzz buffer allocation. Ensure this memory contains specific bytes to pass the early-return check (type & ATTACH_TYPE_CURSIVE).
3. Trigger a Left-to-Right CursivePosFormat1 lookup linking glyph 0 and glyph 32768 to plant the -32768 chain value.
4. Trigger a Right-to-Left CursivePosFormat1 lookup to reverse the chain, triggering the negation overflow and corrupting the chain.
5. Trigger another lookup to traverse the corrupted chain. The engine will perform an OOB read at the groomed -640 KB offset, followed by OOB writes (e.g., writing 0 and negated offsets) to that same location.
6. Use these OOB write primitives to corrupt adjacent object metadata or vtables, leading to renderer RCE.

Suggested Fix

1. Reject INT16_MIN: In CursivePosFormat1::apply, explicitly reject assignments where the calculated distance is -32768 (since its negation cannot be represented in 16 bits).
2. Bounds Checking: Add an explicit bounds check inside reverse_cursive_minor_offset() right after computing j = (int) i + chain to verify that j < buffer->len before performing any recursive calls or array accesses. (Similar to the checks in propagate_attachment_offsets()).

Evaluated with Chrome root at commit: a3f5fcb392f2902650ca2b71820e7e418787e18b

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. Please feel free to reach out to me if you have concerns or feedback.