Automatically applying components based on crash stacktrace and information from OWNERS files.

If this is incorrect, please apply the Test-Predator-Wrong-Components label.

Automatically adding ccs based on OWNERS file / target commit history.

If this is incorrect, please add ClusterFuzz-Wrong label.

Automatically assigning owner based on suspected regression changelist https://chromium.googlesource.com/chromium/src/+/66bcb57a90138959ea5a42de0677ceb3cc0a40f0 (Reland "cc, gpu: Make serialization code bitness agnostic.").

If this is incorrect, please let us know why and apply the Test-Predator-Wrong-CLs label. If you aren't the correct owner for this issue, please unassign yourself as soon as possible so it can be re-triaged.

scroggo: can you take a look at this? The reproduce tool should likely be able to reproduce this easily.

It looks like there's potentially a number of out of bounds reads that are guarded by asserts in that function.  Naively, should these be conditionals + early outs?

These asserts are intended to be guaranteed to be true, based on the code above, rather than expected to be true based on what's in the compressed image.

Based on where we are in the switch statement [1], the |headerType| must be one of kInfoV3_BmpHeaderType, kInfoV4_BmpHeaderType, or kInfoV5_BmpHeaderType. (kInfoV2_BmpHeaderType would have exited out just above the assert [2].)

|headerType| is computed from |infoBytes| [3], and for kInfoV3, V4, or V5, infoBytes must be 56, 108, or 124 [4][5]. |infoBytesRemaining| is just |infoBytes| - 4 [6], so it must be 52, 104, or 120.

It looks like there is a typo in the assert. It should be >= 52. That would match both the comment above ("we are guaranteed to be able to read *at least* this size"), and what is happening below (we're reading 4 bytes starting at 48).

[1] https://skia.googlesource.com/skia/+/80c6909bf7ee86e671cc8cbbbb3e5f470e98ebd4/src/codec/SkBmpCodec.cpp#347
[2] https://skia.googlesource.com/skia/+/80c6909bf7ee86e671cc8cbbbb3e5f470e98ebd4/src/codec/SkBmpCodec.cpp#359
[3] https://skia.googlesource.com/skia/+/80c6909bf7ee86e671cc8cbbbb3e5f470e98ebd4/src/codec/SkBmpCodec.cpp#197
[4] https://skia.googlesource.com/skia/+/80c6909bf7ee86e671cc8cbbbb3e5f470e98ebd4/src/codec/SkBmpCodec.cpp#91
[5] https://skia.googlesource.com/skia/+/80c6909bf7ee86e671cc8cbbbb3e5f470e98ebd4/src/codec/SkBmpCodec.cpp#104
[6] https://skia.googlesource.com/skia/+/80c6909bf7ee86e671cc8cbbbb3e5f470e98ebd4/src/codec/SkBmpCodec.cpp#203

Fix in Skia is at https://skia-review.googlesource.com/c/skia/+/164604

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

commit 57862f68330e3bb48ae0ce89023ac4d8d24e67fe
Author: Leon Scroggins III <scroggo@google.com>
Date: Tue Oct 23 15:47:51 2018

Fix an assert in SkBmpCodec::ReadHeader

Bug:  chromium:897389 

The comment seems to imply that infoBytesRemaining should be at least 52
(inclusive). This matches the code below (we read 4 bytes starting at
offset 48). In addition, since this must be one of
kInfoV3_BmpHeaderType, kInfoV4_BmpHeaderType, or kInfoV5_BmpHeaderType,
It is valid for infoBytesRemaining to be 52 (and no less).

Change-Id: I330460f1eb5d372feb622588e26ea3f3a8ddad1e
Reviewed-on: https://skia-review.googlesource.com/c/164604
Commit-Queue: Leon Scroggins <scroggo@google.com>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Auto-Submit: Leon Scroggins <scroggo@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>

[modify] https://crrev.com/57862f68330e3bb48ae0ce89023ac4d8d24e67fe/src/codec/SkBmpCodec.cpp

Thanks for the explanation!  Out of curiosity, are y'all fuzzing the image codecs directly?

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

commit 5148619c4fb030e65704fdd93e09d5457eebc392
Author: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
Date: Tue Oct 23 18:12:45 2018

Roll src/third_party/skia 62b3004439ca..c88cc779efdb (5 commits)

https://skia.googlesource.com/skia.git/+log/62b3004439ca..c88cc779efdb


git log 62b3004439ca..c88cc779efdb --date=short --no-merges --format='%ad %ae %s'
2018-10-23 reed@google.com remove (unused) vertical-text
2018-10-23 mtklein@google.com SkEdgeBuilder refactoring
2018-10-23 scroggo@google.com Fix an assert in SkBmpCodec::ReadHeader
2018-10-23 recipe-roller@chromium.org Roll recipe dependencies (trivial).
2018-10-23 caryclark@skia.org remove extra include


Created with:
  gclient setdep -r src/third_party/skia@c88cc779efdb

The AutoRoll server is located here: https://autoroll.skia.org/r/skia-autoroll

Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md

If the roll is causing failures, please contact the current sheriff, who should
be CC'd on the roll, and stop the roller if necessary.

CQ_INCLUDE_TRYBOTS=luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux-chromeos-compile-dbg;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel

BUG= chromium:897389 
TBR=brianosman@chromium.org

Change-Id: Ie5c66b5069f45001d9a9b9a68b50e89026e7b7b2
Reviewed-on: https://chromium-review.googlesource.com/c/1296852
Reviewed-by: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
Commit-Queue: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#602023}
[modify] https://crrev.com/5148619c4fb030e65704fdd93e09d5457eebc392/DEPS

> Out of curiosity, are y'all fuzzing the image codecs directly?

Yes, but our fuzzer missed this one.

Or I should say that it hasn't found this one. It has found plenty; no blame on the fuzzer.

ClusterFuzz has detected this issue as fixed in range 602019:602023.

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

Fuzzer: libFuzzer_paint_op_buffer_eq_fuzzer
Job Type: libfuzzer_chrome_asan_debug
Platform Id: linux

Crash Type: Abrt
Crash Address: 0x053900157c2a
Crash State:
  sk_abort_no_print
  SkBmpCodec::ReadHeader
  SkBmpCodec::ReadHeader
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan_debug&range=578890:578891
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan_debug&range=602019:602023

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

See https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reference.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 6316913771413504 is verified as fixed, so closing issue as verified.

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