Bug: oss-fuzz:11491, oss-fuzz:11514 and others
Change-Id: I60f05b889a73749ddcde7cf2bf3beabab33b0538
Reviewed-on: https://skia-review.googlesource.com/c/178180
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Auto-Submit: Kevin Lubick <kjlubick@google.com>
Chrome added a public method to validate SkPathRef,
but always called it when validating SkPath. We did too.
Remove the SkPathRef entry point, validate SkPathRef
when validating SkPath, and remove Skia's callers.
(Chrome has already been fixed.)
TBR=reed@google.comR=fmalita@chromium.org
Bug:913930
Change-Id: I0828b00b42cc1f031b4216ddeace50f80aa21e62
Reviewed-on: https://skia-review.googlesource.com/c/177065
Commit-Queue: Cary Clark <caryclark@skia.org>
Auto-Submit: Cary Clark <caryclark@skia.org>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Doesn't look like we need to distinguish these if we just
write them as the simple
1) load the right number of bytes
2) clamp to [min,max]
This makes enum fuzzing independent of its underlying type, and may make
it easier to see the mapping from fuzzed byte stream to
nextRange()/nextEnum() values.
Change-Id: I9f785f94f513a0087ad7151b5e7bc14ddbe9314a
Reviewed-on: https://skia-review.googlesource.com/c/171820
Commit-Queue: Mike Klein <mtklein@google.com>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
This CL renames FuzzPath() to FuzzNicePath() to remind us that it's
meant to create paths that a user could reasonably want to create
in good faith, to pass to Skia via its API, etc.
Then, add fuzz_nice_rect(), and have FuzzNicePath() use that to create
its rectangles and use FuzzNiceMatrix() to create its matrices, just
like we already use FuzzNiceRRect() to create rounded rectangles and
FuzzNicePath() itself to create sub-paths.
Using fuzz_nice_rect() should be the fix for the attached bug.
Using FuzzNiceMatrix() is by analogy, more preemptive.
While we're at it, rename BuildPath to FuzzEvilPath, so the contrast
with FuzzNicePath is more clear.
Update the assertions that we create a valid path in FuzzNicePath()
to tell us where things went wrong if they do.
Bug: oss-fuzz:10667, skia:8384
Change-Id: I6d802182a62815cd969c65cf0479609f64b1da55
Reviewed-on: https://skia-review.googlesource.com/156840
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
This will point out if something's gone screwy earlier in Debug builds.
Bug: oss-fuzz:10488
Change-Id: Ib091ada75344140bbe2932e5c2f1e2257f05019b
Reviewed-on: https://skia-review.googlesource.com/156660
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
As far as I can tell, the attached bugs are self-inflicted wounds.
Bug: skia:8383, oss-fuzz:10378
Change-Id: Ie0bee292982d9e56193b90c04fef5e43bb2e36d4
Reviewed-on: https://skia-review.googlesource.com/156249
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Some oss-fuzz bugs (like the linked one) would not reproduce
in Skia proper due to the fact that there were subtle overloads
of the various Fuzz::next() methods in FuzzCanvas.cpp that
were pulled in in Skia proper, but not oss-fuzz.
This puts all of them in to FuzzCommon.h and makes the
matrix and rrect ones opt-in (fuzz_matrix, fuzz_rrect).
Additionally, this renames fuzz.cpp -> FuzzMain.cpp so we
can properly include Fuzz.cpp in oss-fuzz without
having two mains.
Bug: oss-fuzz:10378
Change-Id: I6cf9afb471781b9fadb689482109a1e5662358b5
Reviewed-on: https://skia-review.googlesource.com/154900
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
