Closed Bug 1243597 (CVE-2016-2795) Opened 4 years ago Closed 4 years ago
Use of uninitialised memory in [@graphite2::File
Face::get _table _fn]
This was found while fuzzing graphite2 1.3.5 (and is in 1.3.4) This uninitialised memory can also end up being used in calls to malloc(), fread() and fseek() NOTE: There is an additional issue at the end of the log, a use of uninitialised memory in graphite2::TtfUtil::CheckTable.
On 64 bit graphite rejects the font as invalid. Was this tested on a different architecture?
This was found using a 64-bit build of graphite running under valgrind. When I run this font I see the valgrind errors followed by "Ran graphite2 in 0.001934s (0 glyphs)" The command I ran was: $ valgrind -q ./comparerenderer -n -f test_case.ttf -t test_string.txt -s 12
Are the errors perhaps generated during the checking process that ends up rejecting the font?
fixed upstream in a8b3ac2aed0eb132cd80efe7de88f8153e73c829
Verified with graphite revision aed0effc27edfb9da441dce3c77f5a1a3fd9f7db
You need to log in before you can comment on or make changes to this bug.