Mon 21 Sep 2015 02:20:04 PM UTC, comment #10:
Thanks, the part is changed as your review, and committed.
|
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 )
with
+ if ( FT_MAC_RFORK_MAX_LEN < temp ||
+ FT_MAC_RFORK_MAX_LEN - temp < pfb_len+ 6 )
to avoid potential overflow.
|
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)
|
Tue 15 Sep 2015 06:51:44 PM UTC, comment #7:
Is this about Mac resourse forks? Those are 16MB maximum.
http://www.ski-epic.com/2015_macintosh_resource_forks/index.html
http://avid.force.com/pkb/articles/en_US/troubleshooting/en250749
|
Sat 12 Sep 2015 08:22:08 AM UTC, comment #6:
OK, let me check.
|
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...
|
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
|
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 :-)
|
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.
|
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:
s/<freetype.h>/FT_FREETYPE_H/
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.
|
Thu 10 Sep 2015 11:12:42 PM UTC, original submission:
Hi.
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)
|