Looks like SkPathRef needs to be validated.  Skia asserts on this, so probably we need to change this function to return a bool and then assert on the return value in Skia so that cc serialization code can reuse it.

The following revision refers to this bug:
  https://skia.googlesource.com/skia/+/ad8da8ea990d22fa717ec1ae7c3ad628d74682b8

commit ad8da8ea990d22fa717ec1ae7c3ad628d74682b8
Author: Adrienne Walker <enne@chromium.org>
Date: Thu Aug 10 20:22:35 2017

Expose SkPath validation as boolean

As a part of serializing SkPaths, I want to be able to know (without
asserting) whether or not a path is valid so that I can discard
potentially malicious deserialized paths.

Currently, SkPath(Ref) both just have asserting validation functions
which can't be used externally.  This patch adds accessors that don't
assert.

Bug:  chromium:752755  skia:6955
Change-Id: I4d0ceb31ec660b87e3fda438392ad2b60a27a0da
Reviewed-on: https://skia-review.googlesource.com/31720
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Mike Reed <reed@google.com>

[modify] https://crrev.com/ad8da8ea990d22fa717ec1ae7c3ad628d74682b8/src/core/SkPathRef.cpp
[modify] https://crrev.com/ad8da8ea990d22fa717ec1ae7c3ad628d74682b8/src/core/SkPath.cpp
[modify] https://crrev.com/ad8da8ea990d22fa717ec1ae7c3ad628d74682b8/include/core/SkPath.h
[modify] https://crrev.com/ad8da8ea990d22fa717ec1ae7c3ad628d74682b8/include/private/SkPathRef.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4905fcbdfdda1b0553ca49f489451624b8ca220c

commit 4905fcbdfdda1b0553ca49f489451624b8ca220c
Author: Adrienne Walker <enne@chromium.org>
Date: Tue Aug 15 20:19:28 2017

Validate SkPath when serializing

Use newly exposed Skia functions.  Also, instead of validating all data
types, just validate all pushed ops to make sure that ops are valid
prior to serialization.

Bug:  752755 
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I5971da644f5a729ff17da8933962eef9629cde2e
Reviewed-on: https://chromium-review.googlesource.com/612539
Reviewed-by: Vladimir Levin <vmpstr@chromium.org>
Commit-Queue: enne <enne@chromium.org>
Cr-Commit-Position: refs/heads/master@{#494521}
[modify] https://crrev.com/4905fcbdfdda1b0553ca49f489451624b8ca220c/cc/paint/paint_op_buffer.h
[modify] https://crrev.com/4905fcbdfdda1b0553ca49f489451624b8ca220c/cc/paint/paint_op_buffer_unittest.cc

The following revision refers to this bug:
  https://skia.googlesource.com/skia/+/d6b28f7bc8c84ee952c433d54861620e403b990f

commit d6b28f7bc8c84ee952c433d54861620e403b990f
Author: Adrienne Walker <enne@chromium.org>
Date: Tue Aug 22 21:13:07 2017

Don't validate() in ~SkPathRef

If an SkPathRef is constructed from arbitrary memory, it might not be
valid.  However, any SkPathRef should be able to be destroyed cleanly.

An alternative to this would be to have CreateFromBuffer always do
the validation (even in release builds), return null for invalid ones,
and do the cleanup itself, but this seems like extra complication and
maybe not something general release builds want.

Bug: chromium: 752755
Change-Id: I1d509a5d5d0b173c20162ff79d731d6c8b4b6fb4
Reviewed-on: https://skia-review.googlesource.com/37321
Commit-Queue: Adrienne Walker <enne@chromium.org>
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>

[modify] https://crrev.com/d6b28f7bc8c84ee952c433d54861620e403b990f/src/core/SkPathRef.cpp

ClusterFuzz has detected this issue as fixed in range 496518:496577.

Detailed report: https://clusterfuzz.com/testcase?key=6015597325582336

Fuzzer: libFuzzer_paint_op_buffer_fuzzer
Job Type: libfuzzer_chrome_asan_debug
Platform Id: linux

Crash Type: Abrt
Crash Address: 0x03e900006a4c
Crash State:
  sk_abort_no_print
  SkPathRef::validate
  SkPathRef::points
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan_debug&range=491099:491177
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan_debug&range=496518:496577

Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=6015597325582336

See https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reproducing.md for more information.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.

ClusterFuzz testcase 6015597325582336 is verified as fixed, so closing issue as verified.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.