Float-cast-overflow in WebCoreDoubleToSkScalar |
||||
Issue descriptionDetailed report: https://cluster-fuzz.appspot.com/testcase?key=5506706831572992 Fuzzer: inferno_twister Job Type: linux_ubsan_chrome Platform Id: linux Crash Type: Float-cast-overflow Crash Address: Crash State: WebCoreDoubleToSkScalar blink::affineTransformToSkMatrix blink::GraphicsContext::concatCTM Regressed: https://cluster-fuzz.appspot.com/revisions?job=linux_ubsan_chrome&range=435261:438085 Minimized Testcase (0.42 Kb): https://cluster-fuzz.appspot.com/download/AMIfv94H9T2eOHPPbD7uN34E2vcvMGwk3XdzH3F_ziU58psw0A3jTIaHX3a8VRHziV1W7r6PKNCBQyIUJWPlAVDi19gC8d3VbThf-YaPnANPx__pFH6qFb3wDFvrlnDXkoT6T1dr113xKVolvKrHXd1adgmHN8G6PA?testcase_id=5506706831572992 Additional requirements: Requires HTTP Issue filed automatically. See https://dev.chromium.org/Home/chromium-security/bugs/reproducing-clusterfuzz-bugs for more information.
,
Dec 31 2016
schenney@, could you PTAL? This looks possibly related to issue 675180 (also overflow in a paint/graphics-related transformation) although there are also some differences (int-vs-float overflow and transformation happening in paint-vs-skia code). My change (mentioned in #c1 above) only renamed some identifiers and shouldn't have caused any behavior changes. I hope that somebody from third_party/WebKit/Source/core/paint/OWNERS can take a look.
,
Dec 31 2016
+reed@ to CC (based on #c1)
,
Jan 3 2017
I can look into this.
,
Jan 17 2017
The change that caused ubsan to start catching float overflow has been reverted, so this is now showing up as fixed by clusterfuzz.
In any event, the problem is with SkDoubleToScalar:
inline SkScalar WebCoreDoubleToSkScalar(double d) {
return SkDoubleToScalar(std::isfinite(d) ? d : 0);
}
Any overflow check should appear in SkDoubleToScalar.
|
||||
►
Sign in to add a comment |
||||
Comment 1 by msrchandra@chromium.org
, Dec 23 2016Components: Blink>Layout
Labels: Test-Predator-Correct-CLs
Owner: lukasza@chromium.org
Status: Assigned (was: Untriaged)