Closed Bug 1243597 (CVE-2016-2795) Opened 4 years ago Closed 4 years ago

Use of uninitialised memory in [@graphite2::FileFace::get_table_fn]

Categories

(Core :: Graphics: Text, defect, critical)

defect
Not set
critical

Tracking

()

RESOLVED FIXED
Tracking Status
firefox45 --- fixed
firefox46 --- fixed
firefox47 --- fixed
firefox-esr38 45+ fixed

People

(Reporter: tsmith, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: csectype-uninitialized, sec-moderate, testcase, Whiteboard: [adv-main45+][adv-esr38.7+])

Attachments

(3 files)

Attached file call_stack.txt
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.
Attached file test_case.ttf
On 64 bit graphite rejects the font as invalid. Was this tested on a different architecture?
Flags: needinfo?(twsmith)
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
Flags: needinfo?(twsmith)
Attached file test_string.txt
Are the errors perhaps generated during the checking process that ends up rejecting the font?
Flags: needinfo?(twsmith)
fixed upstream in a8b3ac2aed0eb132cd80efe7de88f8153e73c829
Verified with graphite revision aed0effc27edfb9da441dce3c77f5a1a3fd9f7db
Flags: needinfo?(twsmith)
Status: NEW → RESOLVED
Closed: 4 years ago
Depends on: 1252311
Resolution: --- → FIXED
Whiteboard: [adv-main45+][adv-esr38.7+]
Group: gfx-core-security → core-security-release
Alias: CVE-2016-2795
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.