Closed Bug 1253501 Opened 8 years ago Closed 8 years ago

graphite2: OOM in [@Parameters::testFileFont()] gr2FontTest.cpp

Categories

(Core :: Graphics: Text, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: tsmith, Unassigned)

References

(Blocks 1 open bug)

Details

(4 keywords, Whiteboard: [gfx-noted])

Attachments

(2 files)

Attached file call_stack.txt
This was found while fuzzing graphite2 latest revision (bc5409c573aa9ecccacd18cf713021272998cd35)

This is not a sec issue it is a bug in the test harness. I am hiding this bug because of the large number of bugs that have been found and I would like to avoid any unwanted attention until things calm down.

The problem is in gr2fonttest/gr2FontTest.cpp
> size_t *map = (size_t*)malloc((gr_seg_n_slots(pSeg) + 1) * sizeof(size_t));

(gr_seg_n_slots(pSeg) + 1) * sizeof(size_t) return a large number, which triggers an OOM. This is really no big deal in the context of the test harness however it does slow down fuzzing when a large amount of memory is allocated. Also I assume this will lead to an OOM crash if the function is used by another application (Firefox?) and a bad font is processed. So my question is should there be a limit on the number of slots? or should that check be made in the application using the library?

To reproduce run:
./gr2fonttest test_case.ttf -auto
Attached file test_case.ttf
Fixed? in a6432e594a77c03bfcd9ba2dee5658c5a14cdccb
Verified with graphite revision 520d76818052772d614e581dacea69499b912be6
Whiteboard: [gfx-noted]
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Group: gfx-core-security → core-security-release
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.