Predator could not provide any possible suspects.
Assigning to the concern owner from CL --
https://chromium.googlesource.com/chromium/src/+log/219e1da7d71acae806e2223332504a426f8a6d65..5639cf6992298065a77ccc6102ed55bace500b8c?pretty=fuller&n=10000

Suspecting Commit#
https://chromium.googlesource.com/chromium/src/+/4fed3346549a90c0de40c02f6388e19e8151e92a

@cblume -- Could you please look into the issue, kindly re-assign if this is not related to your changes.
Thank You.

This may already be fixed. I see the original report (linked from #1) was created on the 26th. Scroggo@ has found and fixed a bug that seems very similar.

If it is something different I'll look into it.

+Scroggo@

Indeed, this sounds like issue 757375, and the source linked to by this report [1] does not include the fix [2].

It looks like the third frame of the image has an error. In order for this to be the same bug, the fourth frame needs to depend on the third (it does - it is subset) and we'd need to be decoding the fourth frame without having attempted to decode the third (which would have called setFailed). I haven't yet dug into that to confirm.

[1] https://chromium.googlesource.com/chromium/src/+/72d71de71b59d95c69866afebd8dc070e45c12ce/third_party/WebKit/Source/platform/image-decoders/gif/GIFImageDecoder.cpp#259
[2] https://chromium-review.googlesource.com/627118

ClusterFuzz has detected this issue as fixed in range 496287:501540.

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

Fuzzer: noel-image-flip
Job Type: linux_asan_chrome_v8_arm
Platform Id: linux

Crash Type: Null-dereference WRITE
Crash Address: 0x0000006c
Crash State:
  SkCodec::startIncrementalDecode
  blink::GIFImageDecoder::Decode
  blink::GIFImageDecoder::Decode
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=linux_asan_chrome_v8_arm&range=495222:495316
Fixed: https://clusterfuzz.com/revisions?job=linux_asan_chrome_v8_arm&range=496287:501540

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

See https://github.com/google/clusterfuzz-tools 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 4511494711803904 is verified as fixed, so closing issue as verified.

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

We've solved the mystery!

This bug was indeed fixed.
When I re-ran the test against HEAD, it seemed to not be fixed. But that is because 32-bit V8 ARM builds were broken for 2 weeks due to https://bugs.chromium.org/p/chromium/issues/detail?id=760120

So running against "HEAD" wasn't really running against HEAD. It was running against the last build, which didn't include the fix.