627295 - UMR [@ nsSVGGlyphFrame::PaintSVG] [@ _cairo_gstate_stroke]

Status: RESOLVED FIXED

(Core :: SVG, defect)

Description

[Jesse Ruderman]

Attachment: valgrind complaint

gfx/tests/crashtests/385228-1.svg triggers a UMR (use of uninitialized memory).

Uninitialized memory caused by the stack allocation of nsSVGGlyphFrame::PaintSVG is used in _cairo_gstate_stroke.

Comment 1

[Robert Longson [:longsonr]]

cairo-gstate.c:1069 on my trunk build is:

if (gstate->stroke_style.line_width <= 0.0)

Now nsSVGGlyphFrame::PaintSVG calls SetupCairoStroke(gfx) followed by gfx->Stroke() which ends up at the line above.

nsSVGGeometryFrame::SetupCairoStroke(gfx) calls nsSVGGeometryFrame::SetupCairoStroke which calls SetupCairoStrokeGeometry which calls aContext->SetLineWidth(width) (unless the width is <=0 which it appears not to be in this case according to my debugging).

aContext->SetLineWidth(width) eventually ends up in _cairo_gstate_set_line_width which is:

gstate->stroke_style.line_width = width;

So I don't understand where the UMR is coming from. 

Does something different to the above sequence of events happen on Linux?

Comment 2

[Robert Longson [:longsonr]]

See bug 658499 too.

Comment 3

[Robert Longson [:longsonr]]

bug 889736 removed nsSVGGlyphFrame

Comment 4

[Al Billings [:abillings - ex-MoCo]]

Did this only affect Firefox 28?

Comment 5

[Daniel Veditz [:dveditz]]

Given it was filed three years ago I'd say "no".

Bug 889736 isn't something we'd back-port and we don't need a band-aide patch for this low severity bug. A UMR of a stack-allocated variable /can/ be exploited, but you'd usually want it to be something like a length variable or a pointer and not a drawing dimension.