Automatically assigning owner based on suspected regression changelist https://chromium.googlesource.com/chromium/src/+/8023e8bac2ba9222b268d5e84cdcae72332ff54f (Use CRYPTO_BUFFER for ParsedCertificate storage.).

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 fuzzer doesn't use HTTPS or afaict, use certs in any way. And the backtrace doesn't look related either. The backtrace ends in header parsing code.

I'm not sure if we really care about hardening our code against CPU usage.  It looks like this one is targeting the vary parser (Also, the CL that should technically be blamed for this is whatever CL increased the length passed to fuzzers)

Any reason you think it's vary-specific? The backtrace looks like generic header parsing.

At any rate, I'll check whether this is an infinite loop, and whether we have any quadratic-or-worse behavior, since both of those would likely need fixing.

The test file looks to be mostly just a big vary header.

It takes about the same amount of time if it's changed to be a 'very' header. 

Cutting the file size in half, however, seems to cut execution time 4x, so we may indeed have a complexity problem.  

So looks like the fuzzer is feeding bytes one-by-one, and we just keep rescanning the whole thing looking for \n\n (or \n\r\n ?). Probably avoidable (we only really need to rescan 2 bytes every time, I think), but it may not be worth worrying about this particular scenario, since it's not like one can just feed a header and make us spend 15 seconds on it. 

Thanks for the investigation - if this is a general parser perf issue (Or a fuzzer-specific parse issue), not a cache bug...And not a priority 1 bug.

More generally, DoS-style attacks / timeouts are not generally considered P-1 bugs.

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

commit 487a3f483473917a7bbf73626278e61cd20aaef7
Author: Matt Menke <mmenke@chromium.org>
Date: Thu Feb 22 20:57:55 2018

HttpStreamParser:  Avoid O(n^2) search for end of headers.

The old code search through the entire buffer for the end of headers
on each read. This is fine in practice, with release builds, but in
fuzzer builds with memory instrumentation, it can lead to timeouts.

The new code just searches through the subset of received data where
the double terminal line break can occur, each time new data is
received.

Bug:  813202 
Change-Id: I0d8b57e9ad9c2c12004e9668cd0704de78065331
Reviewed-on: https://chromium-review.googlesource.com/931645
Reviewed-by: Maks Orlovich <morlovich@chromium.org>
Commit-Queue: Matt Menke <mmenke@chromium.org>
Cr-Commit-Position: refs/heads/master@{#538559}
[modify] https://crrev.com/487a3f483473917a7bbf73626278e61cd20aaef7/net/http/http_stream_parser.cc
[modify] https://crrev.com/487a3f483473917a7bbf73626278e61cd20aaef7/net/http/http_stream_parser.h
[modify] https://crrev.com/487a3f483473917a7bbf73626278e61cd20aaef7/net/http/http_stream_parser_unittest.cc

ClusterFuzz has detected this issue as fixed in range 538543:538565.

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

Fuzzer: libFuzzer_net_http_stream_parser_fuzzer
Job Type: libfuzzer_chrome_msan
Platform Id: linux

Crash Type: Timeout (exceeds 25 secs)
Crash Address: 
Crash State:
  net_http_stream_parser_fuzzer
  
Sanitizer: memory (MSAN)

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_msan&range=452878:452922
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_msan&range=538543:538565

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

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

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

 Issue 816287  has been merged into this issue.