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


You are not allowed to post comments on this tracker with your current authentication level.

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

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

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>
Group administrator
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>
Group 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>
Group administrator
Tue 15 Sep 2015 06:51:44 PM UTC, comment #7: 
Alexei Podtelezhnikov <podtelez>
Group Member
Sat 12 Sep 2015 08:22:08 AM UTC, comment #6: 

OK, let me check.

suzuki toshiya <mpsuzuki>
Group administrator
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>
Group 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>
Group 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>
Group 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>
Group 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.

             -- sort resources by their ids --
             [0]: resource_id=0x0001, offset=0x00000012
             [1]: resource_id=0x0001, offset=0x0000001a
             [2]: resource_id=0x0001, offset=0x00000022
             [3]: resource_id=0x0001, offset=0x0000002a
             [4]: resource_id=0x0001, offset=0x00000032
             [5]: resource_id=0x0001, offset=0x0000003a
             [6]: resource_id=0x0001, offset=0x00000042
             [7]: resource_id=0x0001, offset=0x0000004a
             [8]: resource_id=0x0002, offset=0x00000052
             [9]: resource_id=0x0002, offset=0x0000005a
             [10]: resource_id=0x0002, offset=0x00000062
             [11]: resource_id=0x0002, offset=0x0000006a
             [12]: resource_id=0x0002, offset=0x00000072
             [13]: resource_id=0x0002, offset=0x00000073
             [14]: resource_id=0x0002, offset=0x00000075
             [15]: resource_id=0x01f5, offset=0x00000000
             [16]: resource_id=0x01f6, offset=0x000007fe
             [17]: resource_id=0x01f7, offset=0x00000a14
                 POST fragment #0: length=0x6e742d31
                 POST fragment #1: length=0x43686571
                 POST fragment #2: length=0x2e303031
                 POST fragment #3: length=0x72656174
             too long fragment length makes pfb_len confused: temp=0x72656174
FT_Open_Face: Return 9

Werner LEMBERG <wl>
Group 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>
Group Member


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

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

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.


    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.13-4b48.
    Corresponding source code