This crash is in libyuv: Why are you assigning it to me?

I'm not a libyuv owner or maintainer. Reassigning to fbarchard for investigation. 

If calling code needs to guard against this I can write a patch that does a NULL pointer check on the planes, but that's not going to keep this from happening via some other libyuv user some time in the future.

SetRow_ERMS is like memset.  ERMS means Enhanced Rep Move String, so the function boils down to a single intel instruction - rep movsb.  It takes a pointer, value, and count.
The instruction is available on all Intel cpus, but only used when the cpuid says rep movsb is 'Enhanced', which in practice is Haswell+.

SetPlane is likely the libyuv SetPlane function, which will normally step through rows, but if the rows are continuous, will merge the call into one call of SetRow_ERMS with width * height bytes, for each plane.
Neither SetPlane or SetRow_ERMS checks the pointer, nor has return codes.  The next level up is expected to do parameter sanity checks.  In libyuv that would be I420Rect, but it looks like VpxDecode decode calls SetPlane() directly, likely because different planar formats are supported (e.g. 422, 444).

If you suspect a bug in libyuv assembly, the environment variable LIBYUV_DISABLE_ASM=1 can be used to fall back on a simple C version.
Or the calling code can disable the cpu optimizations with the code equivalent.
libyuv:MaskCpuFlags(1);
will disable all assembly.

Since the issue is likely in libvpx, someone from codec group should take this?

> Since the issue is likely in libvpx, someone from codec group should take this?

@fbarchard: This is a null pointer write happening in libyuv. 

> If you suspect a bug in libyuv assembly, the environment variable LIBYUV_DISABLE_ASM=1 can be used to fall back on a simple C version.

SetRow_C() would crash just as well as SetRow_ERMS() in this situation, but thanks for information. Is it not feasible for libyuv to guard against a crash on a write to a NULL pointer in SetRow()? 

If it's not, then the fix for this probably belongs in media/filters/vpx_video_decoder.cc. 

> Since the issue is likely in libvpx, someone from codec group should take this?

@mmoroz:

How do I reproduce this? The minimized test case does not appear to be a media file, and I'm not sure what to do with it. In the past the clusterfuzz minimized test cases have always included a media file of some sort. Is this a new fuzzing setup?

tomfinegan@, it happens quite often that testcases generated by a fuzzer look more like some garbage than like valid files. Probably this is one of such cases, when the input is so malformed that it doesn't look like a media file.

To reproduce the crash you need to build media_vpx_video_decoder_fuzzer following this instruction: https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reproducing.md

And then run it with path to testcase passed as an argument:
$ ./media_vpx_video_decoder_fuzzer ./fuzz-3-media_vpx_video_decoder_fuzzer 
INFO: Seed: 2031457561
<...>/out/Release/media_vpx_video_decoder_fuzzer: Running 1 inputs 1 time(s) each.
ASAN:DEADLYSIGNAL
=================================================================
==53529==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x0000031ba5da bp 0x7fff758109e0 sp 0x7fff758109c0 T0)
==53529==The signal is caused by a WRITE memory access.
==53529==Hint: address points to the zero page.
    #0 0x31ba5d9 in SetRow_ERMS third_party/libyuv/source/row_gcc.cc:3022:3
    #1 0x31b7c33 in SetPlane third_party/libyuv/source/planar_functions.cc:1188:5
<...>

I've just managed to reproduce the crash locally.

@mmoroz: Thanks for the repro steps. Since this still looks like a crash in libyuv (your call stack certainly shows that) I'm waiting on fbarchard@ to answer my question in #4 before moving forward on this as I'm interpreting clusterfuzz's scariness value of 10 as "not that scary". 

Yes, scariness: 10 is one of the lowest possible values (or even the lowest one). 

ClusterFuzz has detected this testcase as flaky and is unable to reproduce it in the original crash revision. Skipping fixed testing check and marking it as potentially fixed.

Detailed report: https://cluster-fuzz.appspot.com/testcase?key=6425194553409536

Fuzzer: libfuzzer_media_vpx_video_decoder_fuzzer
Job Type: libfuzzer_chrome_asan
Platform Id: linux

Crash Type: UNKNOWN WRITE
Crash Address: 0x000000000000
Crash State:
  SetRow_ERMS
  SetPlane
  media::VpxVideoDecoder::VpxDecode
  
Regressed: https://cluster-fuzz.appspot.com/revisions?job=libfuzzer_chrome_asan&range=392685:393435

Minimized Testcase (253.97 Kb): https://cluster-fuzz.appspot.com/download/AMIfv97319U7uoCbhLUoAvFI-baLqLDzHeyVf5UVWulVeBIvhpU_l1O0xPOAlSHk9Bs6DLxR1dLVuU-8V7dXonRLi0CAl2owD4-TnszBwlKga5_8vs49ncLC-SsgxVAmI9ysAtFuWtW4pWI8GGCS3jzUqJZQmPS1MsHaSYaNUwUltzFsIfNL2WQ?testcase_id=6425194553409536

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.

Detailed report: https://cluster-fuzz.appspot.com/testcase?key=6750618463240192

Fuzzer: libfuzzer_media_vpx_video_decoder_fuzzer
Job Type: libfuzzer_chrome_asan
Platform Id: linux

Crash Type: UNKNOWN WRITE
Crash Address: 0x000000000000
Crash State:
  SetRow_ERMS
  SetPlane
  media::VpxVideoDecoder::VpxDecode
  
Regressed: https://cluster-fuzz.appspot.com/revisions?job=libfuzzer_chrome_asan&range=396645:396647

Minimized Testcase (3.24 Kb): https://cluster-fuzz.appspot.com/download/AMIfv94VWlDw353DVEYjFY_FDeA6bxm1jB_M1eVKcaTdjZisT7-bRQDncbYSdQMf_fHefrPJJLCyZuOGFH9ZHsML5ZWyDqXLhCQd5xyvTCkAvtlwOyfnPKaytiEHhuYuPwT_01MHw1NZoQjc8FJoqnqFyvFILR1oMg?testcase_id=6750618463240192

Filer: tkonchada

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

ClusterFuzz has detected this issue as fixed in range 402512:402719.

Detailed report: https://cluster-fuzz.appspot.com/testcase?key=6750618463240192

Fuzzer: libfuzzer_media_vpx_video_decoder_fuzzer
Job Type: libfuzzer_chrome_asan
Platform Id: linux

Crash Type: UNKNOWN WRITE
Crash Address: 0x000000000000
Crash State:
  SetRow_ERMS
  SetPlane
  media::VpxVideoDecoder::VpxDecode
  
Regressed: https://cluster-fuzz.appspot.com/revisions?job=libfuzzer_chrome_asan&range=396645:396647
Fixed: https://cluster-fuzz.appspot.com/revisions?job=libfuzzer_chrome_asan&range=402512:402719

Minimized Testcase (3.24 Kb): https://cluster-fuzz.appspot.com/download/AMIfv94VWlDw353DVEYjFY_FDeA6bxm1jB_M1eVKcaTdjZisT7-bRQDncbYSdQMf_fHefrPJJLCyZuOGFH9ZHsML5ZWyDqXLhCQd5xyvTCkAvtlwOyfnPKaytiEHhuYuPwT_01MHw1NZoQjc8FJoqnqFyvFILR1oMg?testcase_id=6750618463240192

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 is verified as fixed, closing issue.

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

Removing EditIssue view restrictions from ClusterFuzz filed bugs. If you believe that this issue should still be restricted, please reapply the label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot