Unable to find actual suspect through code search and also from the provided CL under regression range.

By comparing the stack trace this issue looks similar to   bug 813202  , hence assigning to @mmenke for more updates on this issue.

Thanks!

I see no evidence that this DoS attack is a regression, or related to anything other than the fuzzer infrastructure change allowing up to 1 MB of data to be sent through a fuzzer.  Lowering priority.

Repeatedly hunting down O(n^2) or worse behavior is parsers really doesn't seem a terribly productive use of my time (Nor does treating DoS-style attacks as anything other than P3s).  We may want to limit the size of data passed to most net fuzzers if this continues to be a problem.

I think this is just the time it takes to run 1 post task + 1 base::RunLoop::Run() for every 3 bytes in the input file, in a memory instrumented build.  I'm going to cap input size at 50k.

Also, is there some reason "./out/libfuzzer/net_http_stream_parser_fuzzer ~/Downloads/clusterfuzz-testcase-minimized-net_http_stream_parser_fuzzer-6311494959235072" runs on the test on the entire input string twice?  While we do have fuzzers in net that run through the input data twice, is is not one of them.  I hope we aren't normally doing this, or else it could significantly contribute to the number of timeouts we see.

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

commit be641cd922475715b4cfc5bcba80b13696039ff9
Author: Matt Menke <mmenke@chromium.org>
Date: Wed Mar 21 14:50:50 2018

Place a limit on the number of async operations in FuzzedSocket.

It can take an order of magnitude more time to spin a message loop and
handle a result asynchronously than it does to handle the same result
synchronously, and tests were timing out as a result. Placing a limit
on async results will hopefully reduce the number of fuzzers using
FuzzedSocket that time out.

Bug:  823012 
Change-Id: I110fbf2ce0b96cce12cb84ea21c3f44e6b45005b
Reviewed-on: https://chromium-review.googlesource.com/972377
Commit-Queue: Matt Menke <mmenke@chromium.org>
Reviewed-by: Eric Roman <eroman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#544697}
[modify] https://crrev.com/be641cd922475715b4cfc5bcba80b13696039ff9/net/socket/fuzzed_socket.cc
[modify] https://crrev.com/be641cd922475715b4cfc5bcba80b13696039ff9/net/socket/fuzzed_socket.h

ClusterFuzz has detected this issue as fixed in range 544688:544701.

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

Fuzzer: libFuzzer_net_http_stream_parser_fuzzer
Job Type: libfuzzer_chrome_asan_debug
Platform Id: linux

Crash Type: Timeout (exceeds 25 secs)
Crash Address: 
Crash State:
  net_http_stream_parser_fuzzer
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan_debug&range=523270:523295
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan_debug&range=544688:544701

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

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

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