Find it did not provide any possible suspect.
From the regression range assigning to the concern owner.
https://chromium.googlesource.com/chromium/src/+log/6420f2fefc6438000fe55814cc3d18fe38096915..8cf7cb095499c4627228940c2ab0d07aba839d4f?pretty=fuller

Suspecting the Commit --
https://chromium.googlesource.com/chromium/src/+/29b3abb7b00ec613920892937199d39f684c9493

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

Well, looks like indeed OOM on ~2KB input.

Dale, could you please help to find an owner?

=>fgalligan for triage.

Tom can you look at this?

I tried quickly in vpxdec and no OOM. I also hexdumped the file and didn't really have anything I would normally see in a webm file.

I'm not sure this is a P1. We looked at the binary file some more. I'm not even sure how this is getting to the libvpx decoder. We also don't see a valid stack trace in the bug.

There is no stack-trace, because it is not a crash, it is out-of-memory failure detected in the following way: libFuzzer calls getrusage (https://cs.chromium.org/chromium/src/third_party/libFuzzer/src/FuzzerUtil.cpp?q=GetPeakRSSMb+file:%5Esrc/third_party/libFuzzer/src/&sq=package:chromium&l=279) once per second (https://cs.chromium.org/chromium/src/third_party/libFuzzer/src/FuzzerDriver.cpp?q=RssThread+file:%5Esrc/third_party/libFuzzer/src/&sq=package:chromium&l=253) and compares resource usage against the limit.


Regarding priority, please adjust it properly. P1 is a default value we automatically assign to Out-Of-Memory bugs

As we discussed elsewhere I think we should not be reporting OOMs with MSAN
build since MSAN consumes more RAM compared to e.g. ASAN, and
because MSAN reports don't print the heap profiles. 

For this case, the memory consumption under asan is ~600Mb, which is quite tolerable. 

there is one large allocation of ~400Mb: 
385920039 byte(s) (19%) in 1 allocation(s)
    #0 0x4da0ec in __interceptor_malloc (/usr/local/google/home/kcc/chromium/src/out/libfuzzer-asan/media_vpx_video_decoder_fuzzer+0x4da0ec)
    #1 0x1967fe9 in vpx_memalign third_party/libvpx/source/libvpx/vpx_mem/vpx_mem.c:60:10
    #2 0x19f71d9 in vp8_yv12_realloc_frame_buffer third_party/libvpx/source/libvpx/vpx_scale/generic/yv12config.c:62:38
    #3 0x196a8b2 in vp8_alloc_frame_buffers third_party/libvpx/source/libvpx/vp8/common/alloccommon.c:64:9
    #4 0x1943456 in vp8_decode third_party/libvpx/source/libvpx/vp8/vp8_dx_iface.c:374:13
    #5 0x1952726 in vpx_codec_decode third_party/libvpx/source/libvpx/vpx/src/vpx_decoder.c:116:11
    #6 0x7058b7 in media::VpxVideoDecoder::VpxDecode(scoped_refptr<media::DecoderBuffer> const&, scoped_refptr<media::VideoFrame>*) media/filters/vpx_video_decoder.cc:533:9
    #7 0x704fff in media::VpxVideoDecoder::DecodeBuffer(scoped_refptr<media::DecoderBuffer> const&, base::Callback<void (media::DecodeStatus), (base::internal::CopyMode)1, (base::internal::RepeatMode)1> const&) media/filters/vpx_video_decoder.cc:401:8
    #8 0x706bea in media::VpxVideoDecoder::Decode(scoped_refptr<media::DecoderBuffer> const&, base::Callback<void (media::DecodeStatus), (base::internal::CopyMode)1, (base::internal::RepeatMode)1> const&) media/filters/vpx_video_decoder.cc:432:5
    #9 0x5085d9 in LLVMFuzzerTestOneInput media/filters/vpx_video_decoder_fuzzertest.cc:113:13

Depending on the resolution 400MB is not out of the realm of possibility.

Makes sense. Thanks Kostya and Frank!