The fix LGTM, thanks!

In the freetype/src/sfnt/sfobjs.c file, there is a "woff_open_font" function responsible for processing WOFF (Web Open Font Format) file structures. Among other things, it unpacks potentially zlib-compressed SFNT tables and loads them into a new internal memory stream. In the pre-unpacking code, the following table handling snippet is found:

576:      if ( table->Offset != woff_offset                         ||
577:           table->Offset + table->CompLength > woff.length      ||
578:           sfnt_offset + table->OrigLength > woff.totalSfntSize ||
579:           table->CompLength > table->OrigLength                )
580:      {
581:        error = FT_THROW( Invalid_Table );
582:        goto Exit;
583:      }

Here, basic sanitization is performed to make sure that header entries denoting compressed/uncompressed sizes do not cross certain boundaries and are logically valid. However, on 32-bit builds of FreeType, both expressions in lines 577 and 578 ("table->Offset + table->CompLength" and "sfnt_offset + table->OrigLength") may overflow the 32-bit space if enormously large values of "CompLength" or "OrigLength" are provided in the file.

While the potential "CompLength" overflow does not to anything because of a further FT_FRAME_ENTER macro invocation in line 652, the impact is much higher for "OrigLength". Having the field store an inadequately large value may result in a heap-based buffer overflow in the table decompression, as "OrigLength" is passed as the "output_len" parameter to the FT_Gzip_Uncompress function:

668:        error = FT_Gzip_Uncompress( memory,
669:                                    sfnt + table->OrigOffset, &output_len,
670:                                    stream->cursor, table->CompLength );

Even though the value used to achieve an integer overflow must be very large, we can control the number of bytes written to the output buffer very accurately through the zlib-compressed stream, which greatly facilitates practical exploitation of this vulnerability.

Attached please find a file (poc.woff) which can be used to reproduce the issue: it causes FreeType (or in fact, zlib) to attempt to write 1000000 "A" bytes into a 57072 byte long heap-based buffer, resulting in the following AddressSanitizer report:

ASAN:SIGSEGV
=================================================================
==24751== ERROR: AddressSanitizer: SEGV on unknown address 0xf4300000 (pc 0xf5db17fa sp 0xffce7270 bp 0xf4300000 T0)
AddressSanitizer can not provide additional info.
    #0 0xf5db17f9 (/lib/i386-linux-gnu/libz.so.1+0x77f9)
    #1 0xf5db3bec (/lib/i386-linux-gnu/libz.so.1+0x9bec)
    #2 0xf6157d6b in FT_Gzip_Uncompress freetype2/src/gzip/ftgzip.c:719
    #3 0xf60ee94a in woff_open_font freetype2/src/sfnt/sfobjs.c:668
    #4 0xf60eefe3 in sfnt_open_font freetype2/src/sfnt/sfobjs.c:764
    #5 0xf60ef84c in sfnt_init_face freetype2/src/sfnt/sfobjs.c:871
    #6 0xf601513e in tt_face_init freetype2/src/truetype/ttobjs.c:535
    #7 0xf5fca1f7 in open_face freetype2/src/base/ftobjs.c:1191
    #8 0xf5fcd80a in FT_Open_Face freetype2/src/base/ftobjs.c:2123
    #9 0xf5fca51f in FT_New_Face freetype2/src/base/ftobjs.c:1254
    #10 0x804b5a8 in get_face ft2demos-2.5.3/src/ftbench.c:705
    #11 0x804bc64 in main ft2demos-2.5.3/src/ftbench.c:924
SUMMARY: AddressSanitizer: SEGV ??:0 ??
==24751== ABORTING