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 assigning owner based on suspected regression changelist https://chromium.googlesource.com/chromium/src/+/b56def8da2b40d2c9424b3333acba5356f7412fe ([Cast channel] Add basic fuzzer tests).

If this is incorrect, please let us know why and apply the Test-Predator-Wrong-CLs label. If you aren't the correct owner for this issue, please unassign yourself as soon as possible so it can be re-triaged.

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

Removing RBS label since this bug has been around for a while.

Hmm, I don't quite understand this case. The input size in this case is 65536 (which would obviously cause a problem since MessageFramer assumes 65535 is the max message size), but I did specify libfuzzer_options = [ "max_len=65535" ] in the build. So why is an input of size 65536 being generated? xyzzyz@, do you know?

I have no idea, I have no experience with libfuzzer.

+mmoroz@, could you help imcheng@ and xyzzyz@ with their fuzzing question? Thanks!

Yep! There was a recent discussion regarding confusions with input sizes. Basically, -max_len=N doesn't guarantee that we won't ever try feeding a larger input into the target. That's our bad, we could document that piece better.

However, now it's fixed and there is the following recommendation (from https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/getting_started.md#improving-your-fuzz-target)

<b>
If your target has an input length limit that you would like to strictly enforce, add a sanity check to the beginning of your target function:

  if (size < kMinInputLength || size > kMaxInputLength)
    return 0;
</b>

That is a universal solution that would certainly work with any fuzzing engine we might use. Adding a check like that should be enough to fix this issue.


----------


Also, that feels like an example of how such an error might occur in the real life, if we ever copy raw data into GrowableIOBuffer::StartOfBuffer() without strict boundary checking. But I hope we don't do that :)

Shame, I expected that <b>text</b> would make the text bold :)

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

Thanks for the pointer mmoroz@. I will send out a patch to add the size check.

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

commit 261c6064ac0777d21c1d3a60d13a85bc126142f9
Author: Derek Cheng <imcheng@chromium.org>
Date: Wed Apr 04 20:08:51 2018

[Cast channel fuzzer] Add size check in the fuzzer code.

-max_len=N doesn't guarantee that libfuzzer won't ever try feeding a
larger input into the target. So a check is added to the code to enforce
the size limit.

Bug:  828359 
Change-Id: I2aa1404e618350896636de42a0ecc426946c8401
Reviewed-on: https://chromium-review.googlesource.com/996403
Commit-Queue: Derek Cheng <imcheng@chromium.org>
Reviewed-by: Max Moroz <mmoroz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548174}
[modify] https://crrev.com/261c6064ac0777d21c1d3a60d13a85bc126142f9/components/cast_channel/cast_message_fuzzer.cc

ClusterFuzz has detected this issue as fixed in range 548153:548326.

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

Fuzzer: libFuzzer_cast_message_fuzzer
Job Type: mac_libfuzzer_chrome_asan
Platform Id: mac

Crash Type: Heap-buffer-overflow WRITE {*}
Crash Address: 0x6310000387ff
Crash State:
  cast_message_fuzzer.cc
  start
  
Sanitizer: address (ASAN)

Recommended Security Severity: High

Regressed: https://clusterfuzz.com/revisions?job=mac_libfuzzer_chrome_asan&range=542862:542981
Fixed: https://clusterfuzz.com/revisions?job=mac_libfuzzer_chrome_asan&range=548153:548326

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

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

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

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