kcwu: this looks like an issue uncovered from the fuzzer you just added. Could you ptal and help triage? Thanks!

I can reproduce this locally. However its call stack is unexpected to me.

It crashed inside Vp9CompressedHeaderParser. But IIUC, its header_size_in_bytes is too large and it should report error at line 278
https://cs.chromium.org/chromium/src/media/filters/vp9_parser.cc?q=vp9_parser&sq=package:chromium&l=278
and never reach Vp9CompressedHeaderParser at line 302
https://cs.chromium.org/chromium/src/media/filters/vp9_parser.cc?q=vp9_parser&sq=package:chromium&l=302

I feel either the code is having undefined behavior, or there is bug in ASAN or compiler.
(however, ubsan (is_ubsan_security=true) didn't report anything)

I found a bug in vp9_parser.cc. I'm preparing the fix.

https://chromium-review.googlesource.com/c/566753

This is a serious security regression. If you are not able to fix this quickly, please revert the change that introduced it.

If this doesn't affect a release branch, or has not been properly classified for severity, please update the Security_Impact or Security_Severity labels, and remove the ReleaseBlock label. To disable this altogether, apply ReleaseBlock-NA.

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

URGENT - PTAL.
Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the M61 branch #3163 ASAP to have enough baking time in Beta before Stable promotion. Thank you!

Know that this issue shouldn't block the release?  Remove the ReleaseBlock-Stable label.

Kuang-che, this crash happens in 90% of fuzzer runs: https://clusterfuzz.com/v2/performance-report/libFuzzer_media_vp9_parser_fuzzer/libfuzzer_chrome_asan/latest

It's a blocker for gaining new coverage and performing an efficient continuous testing. It would be awesome if you could finalize and land the fix: https://chromium-review.googlesource.com/c/566753

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

commit c2849f197512852b95f46edd4c7ecd97d76c67ee
Author: Kuang-che Wu <kcwu@chromium.org>
Date: Thu Aug 03 18:20:34 2017

vp9_parser: handle invalid calls properly after failures

If Vp9Parser::ParseNextFrame returned error and the client continued to
call the parser, this may lead to out-of-bounds read. This issue only
affected the fuzzer.

BUG= 741244 

Change-Id: Ic60a5e21a85301af520753cecf2b725e66eddb6d
Reviewed-on: https://chromium-review.googlesource.com/566753
Commit-Queue: Kuang-che Wu <kcwu@chromium.org>
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Reviewed-by: Matthew Wolenetz <wolenetz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#491796}
[modify] https://crrev.com/c2849f197512852b95f46edd4c7ecd97d76c67ee/media/filters/vp9_parser.cc
[modify] https://crrev.com/c2849f197512852b95f46edd4c7ecd97d76c67ee/media/filters/vp9_parser.h

ClusterFuzz has detected this issue as fixed in range 491795:491858.

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

Fuzzer: libFuzzer_media_vp9_parser_fuzzer
Job Type: libfuzzer_chrome_asan
Platform Id: linux

Crash Type: Heap-buffer-overflow READ 8
Crash Address: 0x6070000011eb
Crash State:
  media::BitReaderCore::Refill
  media::BitReaderCore::ReadBitsInternal
  bool media::BitReaderCore::ReadBits<int>
  
Sanitizer: address (ASAN)

Recommended Security Severity: Medium

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan&range=485630:485689
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan&range=491795:491858

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


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

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

kcwu@ - what do you think about merging your fix to M61, risk wise?

The fix CL also contains simple refactoring. I feel the risk is pretty low.

OTOH, the original issue will be only triggered by the fuzzer. It should be okay not merging to M61. (No non-fuzzer code path will call parser after failure).

Should I merge for such case?

Thanks kcwu@. I've requested a merge to 61, please wait for govind@'s approval before merging. (The reasoning being that adversaries are also running their own fuzzers against Chrome looking for security issues, and if they find the issue that can use use it maliciously, so it's worth fixing even if it would never be hit by a user during normal operation)

This bug requires manual review: M61 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), ketakid@(ChromeOS), govind@(Desktop)

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

+awhalley@ for M61 merge review

govind@ - good for 61

Approving merge to M61 branch 3163 based on comment #23.

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

kcwu@, please merge you change ASAP to M61 branch so we can take it in for this week Beta release. Thank you.

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

commit 659b34c2ea4fcfc97d0ed76308c6e07b367b961a
Author: Kuang-che Wu <kcwu@chromium.org>
Date: Wed Aug 16 03:07:50 2017

To M61: vp9_parser: handle invalid calls properly after failures

If Vp9Parser::ParseNextFrame returned error and the client continued to
call the parser, this may lead to out-of-bounds read. This issue only
affected the fuzzer.

BUG= 741244 

Change-Id: Ic60a5e21a85301af520753cecf2b725e66eddb6d
Reviewed-on: https://chromium-review.googlesource.com/566753
Commit-Queue: Kuang-che Wu <kcwu@chromium.org>
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Reviewed-by: Matthew Wolenetz <wolenetz@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#491796}(cherry picked from commit c2849f197512852b95f46edd4c7ecd97d76c67ee)
Reviewed-on: https://chromium-review.googlesource.com/610740
Cr-Commit-Position: refs/branch-heads/3163@{#596}
Cr-Branched-From: ff259bab28b35d242e10186cd63af7ed404fae0d-refs/heads/master@{#488528}
[modify] https://crrev.com/659b34c2ea4fcfc97d0ed76308c6e07b367b961a/media/filters/vp9_parser.cc
[modify] https://crrev.com/659b34c2ea4fcfc97d0ed76308c6e07b367b961a/media/filters/vp9_parser.h

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