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 suspected regression changelists:

[mov] Fix leak of frame_duration_buffer in mov_fix_index(). by dalecurtis@chromium.org - https://chromium.googlesource.com/chromium/third_party/ffmpeg/+/3b3e9cda8f791c8bfa9a9e9f33dae63ddceff1bd

[PATCH] lavf/mov: don't read outside frag_index bounds by jstebbins@jetheaddev.com - https://chromium.googlesource.com/chromium/third_party/ffmpeg/+/fe781b218f3767e474265926fe58f43ccc137a5b

avformat/mov: Check size of STSC allocation by hubbe@google.com - https://chromium.googlesource.com/chromium/third_party/ffmpeg/+/ef5c25779b2e96e8a163f2e0a343c0a08a06af0d

If this is incorrect, please let us know why and apply the Test-Predator-Wrong-CLs label.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/third_party/ffmpeg/+/2aa88d702e397bf00f1f12aacec821a249512bdf

commit 2aa88d702e397bf00f1f12aacec821a249512bdf
Author: Xiaohan Wang <xhwang@chromium.org>
Date: Fri Feb 16 18:41:21 2018

ffmpeg: Fix memset size on ctts_data in mov_read_trun()

The allocated size of sc->ctts_data is
(st->nb_index_entries + entries) * sizeof(*sc->ctts_data).

The size to memset at offset sc->ctts_data + sc->ctts_count should be
(st->nb_index_entries + entries - sc->ctts_count) * sizeof(*sc->ctts_data))

The current code missed |entries| I believe.

BUG= 812567 

Change-Id: I380ea8a60faee87853c9291136bccbb90ab90d13
Reviewed-on: https://chromium-review.googlesource.com/922725
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>

[modify] https://crrev.com/2aa88d702e397bf00f1f12aacec821a249512bdf/libavformat/mov.c
[modify] https://crrev.com/2aa88d702e397bf00f1f12aacec821a249512bdf/chromium/patches/README

For the record, the upstream discussion is at https://patchwork.ffmpeg.org/patch/7607/

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/third_party/ffmpeg/+/7eca0422a7ded44fd5262d2ba7609296cbbd211d

commit 7eca0422a7ded44fd5262d2ba7609296cbbd211d
Author: Xiaohan Wang <xhwang@chromium.org>
Date: Sat Feb 24 00:59:54 2018

Revert "ffmpeg: Fix memset size on ctts_data in mov_read_trun()"

This reverts commit 2aa88d702e397bf00f1f12aacec821a249512bdf.

After upstream and offline discussion. It turns out the memset logic
is confusing. So revert this fix and will upload a new fix shortly.

BUG= 812567 

Change-Id: Id5258b65496c47f31f9dc45a80a7960b2dff4616
Reviewed-on: https://chromium-review.googlesource.com/934922
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>

[modify] https://crrev.com/7eca0422a7ded44fd5262d2ba7609296cbbd211d/libavformat/mov.c
[modify] https://crrev.com/7eca0422a7ded44fd5262d2ba7609296cbbd211d/chromium/patches/README

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/third_party/ffmpeg/+/9ca66eafaf6fbbde11862e1468b365220ca142fd

commit 9ca66eafaf6fbbde11862e1468b365220ca142fd
Author: Xiaohan Wang <xhwang@chromium.org>
Date: Sat Feb 24 01:05:04 2018

ffmpeg: Fix memset size on ctts_data in mov_read_trun() (round 2)

The allocated size of sc->ctts_data is
(st->nb_index_entries + entries) * sizeof(*sc->ctts_data).

The size to memset at offset sc->ctts_data + sc->ctts_count should be
(st->nb_index_entries + entries - sc->ctts_count) *
sizeof(*sc->ctts_data))

The current code missed |entries| I believe, which was introduced in
https://patchwork.ffmpeg.org/patch/5541/.

However, after offline discussion, it seems the original code is much
more clear to read (before https://patchwork.ffmpeg.org/patch/5541/).

Hence this CL revert the memset logic to it's previous state by
remembering the |old_ctts_allocated_size|, and only memset the newly
allocated entries.

BUG= 812567 

Change-Id: Ibe94c7138e5818bfaae76866bfa6619a9b8a2b6b
Reviewed-on: https://chromium-review.googlesource.com/934925
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>

[modify] https://crrev.com/9ca66eafaf6fbbde11862e1468b365220ca142fd/libavformat/mov.c
[modify] https://crrev.com/9ca66eafaf6fbbde11862e1468b365220ca142fd/chromium/patches/README

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

commit d1d61b73d82e3940a775d52de0291b06c5254fc5
Author: Xiaohan Wang <xhwang@chromium.org>
Date: Sat Feb 24 04:10:46 2018

Roll /hdd2/chrome/src/third_party/ffmpeg/ 9ed334093..9ca66eafa (7 commits)

https://chromium.googlesource.com/chromium/third_party/ffmpeg.git/+log/9ed334093692..9ca66eafaf6f

$ git log 9ed334093..9ca66eafa --date=short --no-merges --format='%ad %ae %s'
2018-02-23 xhwang ffmpeg: Fix memset size on ctts_data in mov_read_trun() (round 2)
2018-02-23 xhwang Revert "ffmpeg: Fix memset size on ctts_data in mov_read_trun()"
2018-02-23 dalecurtis Don't invoke trailing garbage discard for every flush.
2018-02-23 dalecurtis Skip trailing junk data when flushing parser.
2018-01-29 dalecurtis avcodec/mpegaudio_parser: Skip APE tags when parsing mp3 packets.
2018-02-15 dalecurtis Parse and drop gain control data, so that SSR packets decode.
2018-02-15 xhwang ffmpeg: Fix memset size on ctts_data in mov_read_trun()

Created with:
  roll-dep /hdd2/chrome/src/third_party/ffmpeg

BUG= 812567 , 794782 

Change-Id: If6e6ce0fea7773d2a431d8ba390b122e094162b3
Reviewed-on: https://chromium-review.googlesource.com/935967
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Commit-Queue: Xiaohan Wang <xhwang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#538983}
[modify] https://crrev.com/d1d61b73d82e3940a775d52de0291b06c5254fc5/DEPS

ClusterFuzz has detected this issue as fixed in range 538981:538988.

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

Fuzzer: libFuzzer_media_pipeline_integration_fuzzer
Job Type: libfuzzer_chrome_asan
Platform Id: linux

Crash Type: Heap-buffer-overflow WRITE {*}
Crash Address: 0x61d000010ced
Crash State:
  mov_read_trun
  
Sanitizer: address (ASAN)

Recommended Security Severity: High

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan&range=517706:517712
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan&range=538981:538988

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

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

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

The fix has been landed on ToT and it's pretty straightforward and low risk (see #10). Request merge to M65 if it's not too late.

This bug requires manual review: We are only 7 days from stable.
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

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

+   awhalley@ for M65 merge review

govind@ - good for 65

Approving merge to M65 branch 3325 for cl listed at #10 based on comments #15 and #17. Please merge now so we can pick it up for this week last beta release. Thank you.

Assuming we don't need a merge for any other CLs besides at #10, correct?

We'd like to take them, but we don't have data back from canary yet, so I haven't requested merge for them yet. That's tracked by  issue 794782 .

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/third_party/ffmpeg/+/19a1302b214c62c56409b69ab5e936796d96209f

commit 19a1302b214c62c56409b69ab5e936796d96209f
Author: Xiaohan Wang <xhwang@chromium.org>
Date: Mon Feb 26 20:00:46 2018

ffmpeg: Fix memset size on ctts_data in mov_read_trun() (round 2)

The allocated size of sc->ctts_data is
(st->nb_index_entries + entries) * sizeof(*sc->ctts_data).

The size to memset at offset sc->ctts_data + sc->ctts_count should be
(st->nb_index_entries + entries - sc->ctts_count) *
sizeof(*sc->ctts_data))

The current code missed |entries| I believe, which was introduced in
https://patchwork.ffmpeg.org/patch/5541/.

However, after offline discussion, it seems the original code is much
more clear to read (before https://patchwork.ffmpeg.org/patch/5541/).

Hence this CL revert the memset logic to it's previous state by
remembering the |old_ctts_allocated_size|, and only memset the newly
allocated entries.

TBR=dalecurtis@chromium.org
BUG= 812567 

Change-Id: Ibe94c7138e5818bfaae76866bfa6619a9b8a2b6b
Reviewed-on: https://chromium-review.googlesource.com/934925
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/938142
Reviewed-by: Xiaohan Wang <xhwang@chromium.org>

[modify] https://crrev.com/19a1302b214c62c56409b69ab5e936796d96209f/libavformat/mov.c
[modify] https://crrev.com/19a1302b214c62c56409b69ab5e936796d96209f/chromium/patches/README

If nothing is pending for M65, pls remove "Merge-Approved-65" label. Thank you.

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/chrome/tools/buildspec/+/92d0b581546d19ae3ac955aa74002a34b6cead37

commit 92d0b581546d19ae3ac955aa74002a34b6cead37
Author: Xiaohan Wang <xhwang@chromium.org>
Date: Mon Feb 26 20:52:42 2018

FYI - See also subsequent  bug 816787  (especially comment 14): it looks like there's a case of uninitialized read allowed if moov processing ignored one or more ctts entries having count <=0, and a later moof had a trun for that track with some further valid samples. mov_build_index doesn't "fill" in that gap for an ignored entry; later attempted read of that part of ctts_data leads to  bug 816787 .

This bug has been closed for more than 14 weeks. Removing security view restrictions.

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