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 OWNERS file / target commit history.

If this is incorrect, please add ClusterFuzz-Wrong label.

Automatically assigning owner based on suspected regression changelist https://chromium.googlesource.com/chromium/src/+/60637aee0733db686859db89ce72b948364cb20c (Landing Recent QUIC changes until Fri May 25 16:11:25 2018 +0000).

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

Looks similar in flavor to  crbug.com/850083 . I believe this should not pose any practical risk since this codepath is behind a feature flag that is disabled.  Frank, can you confirm?

Additional question for Frank: will completion of merging the current batch of IETF changes address this, or does this indicate a bug for which additional changes will be necessary?

An OOB write in a privileged process would normally be Critical. If #7 is correct, we can leave it at High, I believe.

Presumably this affects all QUIC-having platforms.

Is this the relevant flag? If so, it appears the feature is enabled:
https://cs.chromium.org/chromium/src/net/third_party/quic/core/quic_flags_list.h?l=162&rcl=da5bdd0447bb19040c26dfc86debd36955ab98d3

It does look like the new IETF code is "supported" as well (why the fuzzer hit this):
https://cs.chromium.org/chromium/src/net/third_party/quic/core/quic_versions.h?l=103&rcl=8f2f9568808ee117698e0a9008a0b52902d2363e

This is just a heads up that this might be reachable by default. If not, it may be useful to modify the fuzzer to constrain it to only "real" regressions to reduce noise while features are debugged/merged in.

The issue arises only if the software has negotiated version 99 (that is, "IETF QUIC"), which it should never do. The ability to do V99 is protected by a flag ("enable_version_99" or something like that). Given that, it should not be an operational issue.

HOWEVER, given that there have been a few fuzzer-generated issues, I will look into this --- they may all be pointing to a bug in the code that might become a real issue once we have full IETF support done.  

I've added Fan Yang to the list since he has done some of the IETF-QUIC work as well.

Hello. Your friendly security sheriff here!

This strikes me as dangerous to have a bug in code that might at some point be enabled in the future. I think I'd like the code to be fully killed, or place a CHECK(false) somewhere so it can never accidently be enabled - as palmer@ says, this would be a critical security vulnerability if this was ever enabled.

Where is the launch of "enable_version_99" being tracked? Is there a launch bug?

Frank, does the fix for  crbug.com/850083  also address this issue?  If so, would be good to close this bug to avoid confusion.

ClusterFuzz has detected this issue as fixed in range 569389:569451.

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

Fuzzer: libFuzzer_net_quic_stream_factory_fuzzer
Job Type: libfuzzer_chrome_ubsan
Platform Id: linux

Crash Type: UNKNOWN WRITE
Crash Address: 0x000060000010
Crash State:
  quic::QuicConnection::OnAckRange
  quic::QuicFramer::ProcessIetfAckFrame
  quic::QuicFramer::ProcessIetfFrameData
  
Sanitizer: undefined (UBSAN)

Recommended Security Severity: High

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_ubsan&range=564617:564646
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_ubsan&range=569389:569451

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

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 6079232443416576 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 requires manual review: M69 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), kariahda@(iOS), cindyb@(ChromeOS), govind@(Desktop)

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

+awhalley@ (Security TPM) for merge review.

No merge needed.

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

Adding reward-topanel as this bug was found by a Chrome Fuzzer Program contribution. Note to the panel: even though this crash was fixed by the same fix as  issue 850083  was (which was also found by Ned's fuzzer), the crash seems to have security implications in Release build ( issue 850083  was found in Debug). Please consider this for a reward.

Thanks mmoroz@, I'm afraid the VRP panel declined to reward. Not only did this report not lead to us making a change, but the code itself might never have shipped in that state; possible security-none.