Predator could not provide any possible suspects.

From the below CL observing some changes related to 'audio_decoder_fuzzer.cpp' , hence suspecting the same
https://chromium.googlesource.com/chromium/src/+log/6cf9e9ef8b09b264c8af672e9f1798acb3cb2260..bfd138a0d51fe3582b3e127561cc791c01460546?pretty=fuller&n=10000

Suspect CL: https://chromium.googlesource.com/chromium/src/+/4b5068a99a84ff2edb34aa0549afc89aa751ccb4

mmoroz@ -- Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Thanks!

I've landed that fuzzer yesterday, so yes technically this is happening due to my CL.

Unfortunately, there isn't much we can do with OOMs with MSan from a memory-hungry targets (e.g. media). I'm blocking this on another MSan+OOM issue and hope will figure out a universal solution in future.

With audio it's more surprising to see a 2GB allocation, so it might be worth looking at to see why in this case.

Thanks Dale, it seems you're right! I can reproduce this with 57B input even under ASan:

$ out/libfuzzer/audio_decoder_fuzzer ~/Downloads/clusterfuzz-testcase-minimized-audio_decoder_fuzzer-4808810280255488 
INFO: Seed: 776228527
INFO: Loaded 2 modules   (2086685 guards): 22595 [0x7f006b900560, 0x7f006b91666c), 2064090 [0xe7ff150, 0xefdecb8), 
out/libfuzzer/audio_decoder_fuzzer: Running 1 inputs 1 time(s) each.
Running: /usr/local/google/home/mmoroz/Downloads/clusterfuzz-testcase-minimized-audio_decoder_fuzzer-4808810280255488
==119865== ERROR: libFuzzer: out-of-memory (used: 2095Mb; limit: 2048Mb)
   To change the out-of-memory limit use -rss_limit_mb=<N>

Live Heap Allocations: 1238074564 bytes in 1013 chunks; quarantined: 74975 bytes in 32 chunks; 9110 other chunks; total chunks: 10155; showing top 95% (at most 8 unique contexts)
1207959552 byte(s) (97%) in 1 allocation(s)
    #0 0x1fefc0e in __interceptor_posix_memalign /b/build/slave/linux_upload_clang/build/src/third_party/llvm/compiler-rt/lib/asan/asan_malloc_linux.cc:157:3
    #1 0x77e4bbc in av_malloc third_party/ffmpeg/libavutil/mem.c:88:9
    #2 0x77e4bbc in av_mallocz third_party/ffmpeg/libavutil/mem.c:239
    #3 0x77e4bbc in av_mallocz_array third_party/ffmpeg/libavutil/mem.c:196
    #4 0x7785efe in mov_read_stsd third_party/ffmpeg/libavformat/mov.c:2583:21

SUMMARY: libFuzzer: out-of-memory


$ python -c 'print hex(1207959552)'
0x48000000


$ cat ~/Downloads/clusterfuzz-testcase-minimized-audio_decoder_fuzzer-4808810280255488 | xxd
00000000: 0000 0024 6674 7970 6973 6f6d 0000 0200  ...$ftypisom....
00000010: 6973 6f6d 6973 6f32 6176 6331 6d70 7600  isomiso2avc1mpv.
00000020: 2300 0023 0000 01db 7472 616b 0000 0096  #..#....trak....
00000030: 7374 7364 0009 0909 09                   stsd.....


I did a bit more of debugging:

Breakpoint 2, av_mallocz_array (nmemb=150994944, size=8) at ../../third_party/ffmpeg/libavutil/mem.c:193

150994944 * 8 = 0x48000000


Dale, do you know whom we can route this to?

Probably we should take care of it as part of the next ffmpeg roll if there's a reasonable mitigation. This is probably the same as many of the other mp4 oom cases. In MSE we clamp to values that are reasonable given the remainder of the file size.

diff --git a/libavformat/mov.c b/libavformat/mov.c
index abac7fe9bc..9da4580a63 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2568,7 +2568,7 @@ static int mov_read_stsd(MOVContext *c, AVIOContext *pb, MOVAtom atom)
     avio_rb24(pb); /* flags */
     entries = avio_rb32(pb);
 
-    if (entries <= 0) {
+    if (entries <= 0 || entries > (avio_size(pb) - avio_tell(pb)) / 16) {
         av_log(c->fc, AV_LOG_ERROR, "invalid STSD entries %d\n", entries);
         return AVERROR_INVALIDDATA;
     }


That patch will probably fix this, but not sure upstream would take it.

Sent the fix upstream, will see what they say.

Looks like they accepted it, will pull it in.

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

commit 2735761284f040ee91da93b4737116eaf8ad2339
Author: Dale Curtis <dalecurtis@chromium.org>
Date: Mon Sep 10 21:06:20 2018

Roll src/third_party/ffmpeg/ bfe62e18d..bbe6b81a6 (4 commits)

https://chromium.googlesource.com/chromium/third_party/ffmpeg.git/+log/bfe62e18d24f..bbe6b81a6c31

$ git log bfe62e18d..bbe6b81a6 --date=short --no-merges --format='%ad %ae %s'
2018-09-10 dalecurtis Update patches file for new ffmpeg fixes.
2018-09-07 dalecurtis avformat/utils: Don't calculate duration using AV_NOPTS_VALUE for start_time.
2018-08-30 dalecurtis avformat/mov: Error on too large stsd entry counts.
2018-08-22 liberato Fetch upstream and check for upstream commit.

Created with:
  roll-dep src/third_party/ffmpeg

BUG= 879852 ,  826648 
TBR=tguilbert

Change-Id: Ibdec4e7e2ffd3d7d61bdefa71f09814d699bba5b
Reviewed-on: https://chromium-review.googlesource.com/1217040
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Reviewed-by: Thomas Guilbert <tguilbert@chromium.org>
Commit-Queue: Dale Curtis <dalecurtis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#590062}
[modify] https://crrev.com/2735761284f040ee91da93b4737116eaf8ad2339/DEPS

ClusterFuzz has detected this issue as fixed in range 589984:590303.

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

Fuzzer: libFuzzer_audio_decoder_fuzzer
Job Type: libfuzzer_chrome_msan
Platform Id: linux

Crash Type: Out-of-memory (exceeds 2048 MB)
Crash Address: 
Crash State:
  audio_decoder_fuzzer
  
Sanitizer: memory (MSAN)

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_msan&range=546308:546319
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_msan&range=589984:590303

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

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

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