Hide Forgot
Freetype integer underflow While fuzzing some pdf files a few weeks back, I ended up finding an integer underflow in freetype2. Upstream did commit some fixes, so this issue is somewhat public. 1.ttf will generate this error. Patches: http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/src/pshinter/pshglob.c?r1=1.30&r2=1.31&makepatch=1&diff_format=h http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/src/cff/cffload.c?r1=1.73&r2=1.74&makepatch=1&diff_format=h http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/src/type1/t1load.c?r1=1.104&r2=1.105&makepatch=1&diff_format=h The problem is the number of blue values needs to be even. If a font file claims it's odd, freetype2 doesn't handle it well. The crash is seen in src/pshinter/pshglob.c:psh_blues_set_zones_0() What was basically happening is since read_count is an unsigned integer, and is decremented by 2, it is possible to cause an integer underflow by ensuring the value of read_count is an odd number. Once read_count underflows, the loop starts dumping garbage onto the heap. Normally I wouldn't think this is exploitable as it should crash before anything exciting can happen, most graphical applications are multi-threaded, so this does worry me. At the very least this issue is a denial of service bug. The 2.ttf file in the testcase will also trigger a NULL pointer dereference, which I'm not considering a secuirty issue. The patch is here: http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/src/base/ftutil.c?r1=1.17&r2=1.18&makepatch=1&diff_format=h
Created attachment 125556 [details] testcase
Lifting embargo
This issue also affects FC4