bugThe FreeType Project - Bugs: bug #45919, FT_New_Memory_Face consumes 17Gb...


bug #45919: FT_New_Memory_Face consumes 17Gb on a small input

Submitted by:  Kostya Serebryany <kcc>
Submitted on:  Thu 10 Sep 2015 11:12:42 PM UTC  
Severity:  3 - Normal Item Group:  Incorrect behaviour
Status:  Ready For Test Privacy:  Public
Assigned to:  suzuki toshiya <mpsuzuki> Open/Closed:  Closed
Planned Release:  None

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Mon 21 Sep 2015 02:20:04 PM UTC, comment #10:

Thanks, the part is changed as your review, and committed.

suzuki toshiya <mpsuzuki>
Project AdministratorIn charge of this item.
Sun 20 Sep 2015 05:31:39 PM UTC, comment #9:

Looks good, except a single nit. Please replace

+ if ( FT_MAC_RFORK_MAX_LEN < temp ||
+ FT_MAC_RFORK_MAX_LEN < pfb_len + temp + 6 )


+ if ( FT_MAC_RFORK_MAX_LEN < temp ||
+ FT_MAC_RFORK_MAX_LEN - temp < pfb_len+ 6 )

to avoid potential overflow.

Werner LEMBERG <wl>
Project Administrator
Sun 20 Sep 2015 03:52:19 PM UTC, comment #8:

Sorry for lated action, here I drafted a patch;

1) define FT_MAC_RFORK_MAX_LEN 0x00FFFFFFUL in ftbase.h
2) abort when the size of fragment or total length of POST exceeds the max length.
3) abort when the sfnt resource size exceeds the max length.
4) Although Mac OS X's Carbon function seems to return an
error to too-long resource fork, same checking code is inserted.

I've checked with the testing font, and non-malicious-but-too-
long TTF (HanaMinB.dfont) made by fontforge. I have to note
that I can make a file with a resource fork longer than 16MB,
but Carbon API seems to refuse it.

(file #34937)

suzuki toshiya <mpsuzuki>
Project AdministratorIn charge of this item.
Tue 15 Sep 2015 06:51:44 PM UTC, comment #7:

Is this about Mac resourse forks? Those are 16MB maximum.

Alexei Podtelezhnikov <podtelez>
Project Member
Sat 12 Sep 2015 08:22:08 AM UTC, comment #6:

OK, let me check.

suzuki toshiya <mpsuzuki>
Project AdministratorIn charge of this item.
Sat 12 Sep 2015 07:43:29 AM UTC, comment #5:

Toshiya-san, please have a look and fix it! I'm no expert with Mac Resources... The problem is in function `Mac_Read_POST_Resource': with the font attached to this bug report, `pfb_len' gets very large on a 64bit host. Is there a maximum value for this in the specification? Otherwise we should probably introduce an ad-hoc limit...

Werner LEMBERG <wl>
Project Administrator
Fri 11 Sep 2015 08:26:35 PM UTC, comment #4:

I believe this is the offending call stack:

#0 FT_Stream_ReadAt at src/base/ftstream.c:123
#1 0x00000000004e1c1e in FT_Stream_Read at src/base/ftstream.c:114
#2 Mac_Read_POST_Resource at src/base/ftobjs.c:1700
#3 IsMacResource at src/base/ftobjs.c:1840
#4 0x00000000004e2427 in load_mac_face at src/base/ftobjs.c:2046
#5 FT_Open_Face at src/base/ftobjs.c:2198
#6 0x00000000004e2a24 in FT_New_Memory_Face at src/base/ftobjs.c:1256
#7 0x00000000004d69cb in TestOneInput
#8 0x00000000004d6c00 in main

Kostya Serebryany <kcc>
Project Member
Fri 11 Sep 2015 06:28:37 PM UTC, comment #3:

Thanks. The tracing bug is fixed now in git.

Please use gdb, set a breakpoint at FT_Stream_ReatAt, and report a backtrace for the offending call. This helps me better localize the problem.

BTW, I get a 64bit notebook within two weeks :-)

Werner LEMBERG <wl>
Project Administrator
Fri 11 Sep 2015 05:53:31 AM UTC, comment #2:

It is clearly a 64-bit issue because you can't consume 17Gb on a 32-bit system :)

I've re-built the lib with this:
CC="gcc -DFT_DEBUG_LEVEL_ERROR=1 -DFT_DEBUG_LEVEL_TRACE=1" ../freetype2/configure

Running with FT2_DEBUG=any:7 :
TTF driver
SFNT driver
not a font using the SFNT container format
Type 1 driver
not a Type 1 font
CFF driver
SFNT driver
not a font using the SFNT container format
not a CFF font header
CID driver
not a CID-keyed font
PFR driver
not a PFR font
Type 42 driver
not a Type42 font
Windows FNT driver
not a Windows FNT file
PCF driver
not a PCF file
BDF driver
not a BDF file
Segmentation fault (core dumped)

Segv happens here:
(gdb) bt
#0 0x00007ffff71bca03 in _IO_vfprintf_internal (s=<optimized out>, format=<optimized out>, ap=<optimized out>) at vfprintf.c:1661
#1 0x00007ffff71bff31 in buffered_vfprintf (s=s@entry=0x7ffff75301c0 <_IO_2_1_stderr_>, format=format@entry=0x46d44b "Try as dfont: %s ...", args=args@entry=0x7fffffffda58)
at vfprintf.c:2356
#2 0x00007ffff71baeae in IO_vfprintf_internal (s=s@entry=0x7ffff75301c0 <_IO_2_1_stderr>, format=format@entry=0x46d44b "Try as dfont: %s ...", ap=0x7fffffffda58)
at vfprintf.c:1313
#3 0x00007ffff727a85d in __vfprintf_chk (fp=0x7ffff75301c0 <_IO_2_1_stderr>, flag=flag@entry=1, format=format@entry=0x46d44b "Try as dfont: %s ...",
ap=ap@entry=0x7fffffffda58) at vfprintf_chk.c:33
#4 0x000000000046bfeb in vfprintf (__ap=0x7fffffffda58, __fmt=0x46d44b "Try as dfont: %s ...", __stream=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/stdio2.h:127
#5 FT_Message (fmt=fmt@entry=0x46d44b "Try as dfont: %s ...") at /usr/local/google/home/kcc/fuzz/freetype/freetype2/src/base/ftdebug.c:61
#6 0x0000000000413492 in load_mac_face (args=0x7fffffffdd70, aface=0x7fffffffddd8, face_index=0, stream=0x16a0980, library=0x16a0040)
at /usr/local/google/home/kcc/fuzz/freetype/freetype2/src/base/ftobjs.c:2040
#7 FT_Open_Face (library=0x16a0040, args=args@entry=0x7fffffffdd70, face_index=0, aface=0x7fffffffddd8)
at /usr/local/google/home/kcc/fuzz/freetype/freetype2/src/base/ftobjs.c:2194
#8 0x0000000000413704 in FT_New_Memory_Face (library=<optimized out>, file_base=<optimized out>, file_size=<optimized out>, face_index=<optimized out>,
aface=<optimized out>) at /usr/local/google/home/kcc/fuzz/freetype/freetype2/src/base/ftobjs.c:1256
#9 0x0000000000407867 in TestOneInput ()
#10 0x0000000000407961 in main ()

Running w/o any flags it prints:

FT_Stream_ReadAt: invalid read; expected 1853107503 bytes, got 30846

consumes 17Gb and exits normally.

I am happy to be a remote debugger,
but please let me know if you would like to have remote access
to a proper x86_64 box.

Kostya Serebryany <kcc>
Project Member
Fri 11 Sep 2015 04:51:59 AM UTC, comment #1:

Thanks for the report. This seems to be a 64bit issue, since I can't repeat it on my 32bit GNU/Linux box.

Note that there is a typo in your repro.c file:


Please recompile FreeType with debugging and tracing support, then post the output of the demo program if called with

FT2_DEBUG=any:7 repro ...

On my box, function `Mac_Read_POST_Resource' emits the following trace before exiting properly.

Werner LEMBERG <wl>
Project Administrator
Thu 10 Sep 2015 11:12:42 PM UTC, original submission:

I am trying to fuzz freetype2 using llvm.org/docs/LibFuzzer.html
(This is similar to what j00ru has done in 2014, but using
slightly different tools).

The first thing I hit is an input that makes FT_New_Memory_Face
consume 17Gb of RAM

Does this sound like a bug?
At the very least it hurts the ability to fuzz freetype efficiently.

Reproducer (the input and the sample program that calls FT_New_Memory_Face) is attached.

The problem is observed on 2.6 and on fresh git (b6eef5ae7bc5fd3a07f237c8f609d12dd4084130)

Kostya Serebryany <kcc>
Project Member


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #34937:  mps20150921-0045.diff added by mpsuzuki (5KiB - text/x-patch)
file #34852:  crash-cffe89825997844e176346cedd42b6a48a07119e added by kcc (30KiB - application/octet-stream)
file #34853:  repro.c added by kcc (604B - text/x-csrc)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by podtelez (Posted a comment)
  • -email is unavailable- added by mpsuzuki (Posted a comment)
  • -email is unavailable- added by wl (Posted a comment)
  • -email is unavailable- added by kcc (Submitted the item)
  • -email is unavailable- added by kcc

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-09-21 mpsuzuki Open/ClosedOpen => Closed
    2015-09-20 mpsuzuki StatusNeed Info => Ready For Test
    2015-09-20 mpsuzuki Attached File- => Added mps20150921-0045.diff, #34937
    2015-09-12 wl Assigned towl => mpsuzuki
    2015-09-11 wl StatusNone => Need Info
        Assigned toNone => wl
    2015-09-10 kcc Attached File- => Added crash-cffe89825997844e176346cedd42b6a48a07119e, #34852
        Attached File- => Added repro.c, #34853
        Carbon-Copy- => Added j00ru

    Back to the top

    Powered by Savane 3.4