Automatically applying components based on crash stacktrace and information from OWNERS files.

If this is incorrect, please apply the Test-Predator-Wrong-Components label.

Probably same story as with  issue 788537 ,  issue 797825 , and  issue 801811 , but those are when using QUIC, and this is with HTTP/2.  I'll use the same approach to fix it.

wangyix@ noticed this 9 days ago. I'm not sure if they're working on a fix.

I can reproduce locally using the clusterfuzz-provided testcase.  Here's the symbolicated stack trace:

[242686:242686:0209/150006.554721:1300985896866:FATAL:x509_certificate.cc(477)] Check failed: !hostname.empty().
#0 0x7f48641d09fd base::debug::StackTrace::StackTrace()
#1 0x7f48641ceeec base::debug::StackTrace::StackTrace()
#2 0x7f486425793a logging::LogMessage::~LogMessage()
#3 0x7f4864a2da0f net::X509Certificate::VerifyHostname()
#4 0x7f4864a2f716 net::X509Certificate::VerifyNameMatch()
#5 0x7f48653081fe net::SpdySession::CanPool()
#6 0x7f4865331094 net::SpdySession::OnAltSvc()
#7 0x7f48652e87a9 net::BufferedSpdyFramer::OnAltSvc()
#8 0x7f486538f043 net::Http2DecoderAdapter::OnAltSvcEnd()
#9 0x7f4864f52fdb net::AltSvcPayloadDecoder::DecodeStrings()
#10 0x7f4864f52a22 net::AltSvcPayloadDecoder::ResumeDecodingPayload()
#11 0x7f4864f52263 net::AltSvcPayloadDecoder::StartDecodingPayload()
#12 0x7f4864f4f178 net::Http2FrameDecoder::StartDecodingAltSvcPayload()
#13 0x7f4864f4e6e9 net::Http2FrameDecoder::StartDecodingPayload()
#14 0x7f4864f4e124 net::Http2FrameDecoder::DecodeFrame()
#15 0x7f48653893e4 net::Http2DecoderAdapter::ProcessInputFrame()
#16 0x7f4865389103 net::Http2DecoderAdapter::ProcessInput()
#17 0x7f48652e8844 net::BufferedSpdyFramer::ProcessInput()
#18 0x7f4865321fc0 net::SpdySession::DoReadComplete()
#19 0x7f48653211ec net::SpdySession::DoReadLoop()
#20 0x7f486530ff11 net::SpdySession::PumpReadLoop()

This is not quite the same as the bugs mentioned in comment #2, because those relate to receiving invalid PUSH_PROMISE frames, whereas this one seems to be an ALTSVC frame.

The clusterfuzz test data above causes SpdySession::OnAltSvc() to be called with
the following value for its SpdyStringPiece origin argument:

0x0000:  0005 6874 7470 733a 3f2f 7765 2e77 7778  ..https:?/we.wwx
0x0010:  616d 704c 652e 6f72 6765 742e 7777 7861  ampLe.orget.wwxa
0x0020:  0665 2e4c 0000 0403 00                   .e.L.....

This parses as an invalid GURL.

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

commit 203e67e5759b3603a00ff61b0fd5f04d96fa4d0f
Author: Bence Béky <bnc@chromium.org>
Date: Mon Feb 12 21:20:19 2018

Reject HTTP/2 ALTSVC frames with invalid origin.

I have locally verified that the regression test crashes
without the change in spdy_session.cc.

Bug:  810404 
Change-Id: Ic431b2c626c0ef99c82ece9dc4b545f16b6fb498
Reviewed-on: https://chromium-review.googlesource.com/913728
Reviewed-by: Ryan Hamilton <rch@chromium.org>
Commit-Queue: Ryan Hamilton <rch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#536193}
[modify] https://crrev.com/203e67e5759b3603a00ff61b0fd5f04d96fa4d0f/net/spdy/chromium/spdy_session.cc
[modify] https://crrev.com/203e67e5759b3603a00ff61b0fd5f04d96fa4d0f/net/spdy/chromium/spdy_session_unittest.cc

ClusterFuzz has detected this issue as fixed in range 536189:536202.

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

Fuzzer: libFuzzer_net_spdy_session_fuzzer
Job Type: libfuzzer_chrome_asan_debug
Platform Id: linux

Crash Type: CHECK failure
Crash Address: 
Crash State:
  !hostname.empty() in x509_certificate.cc
  net::X509Certificate::VerifyHostname
  net::X509Certificate::VerifyNameMatch
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan_debug&range=527649:527661
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan_debug&range=536189:536202

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

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

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