japhet @ could you please look into this.please feel free to re-assigned back if needed. thanks in advance !

renderer_tree_fuzzer appears to have a generated a case that tried to issue a network request. Because it is single-process, it doesn't have the plumbing for  network requests, and really shouldn't be trying to issue them. We could theoretically defend against this, but only single-process unittests can get blink into this state, so it's not like this is a real bug that we'd ever encounter in production.

Excuse me, but I have to re-open the issue. The fuzzer always quickly hits this crash and cannot find anything else. We need to fix this by any means. If this behavior is not possible in the browser, let's modify the fuzzer to avoid triggering that.

japhet@, any pointers on how we can fix this would be much appreciated!

Removing EditIssue view restrictions from ClusterFuzz filed bugs. If you believe that this issue should still be restricted, please reapply the label.

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

Sorry, this got reopened while I was out on leave and I didn't see it until just now :(

Off the top of my head, I can think of 2 possible ways to resolve this:
* Ensure that no network requests generated by the fuzzer. This means being really careful about what goes in <script> or <img> src attributes, and other fields that indicate a url that should be loaded. You should be able to have them be invalid URLs (to test failure cases), or data: urls (to test success cases).
* Ensure that your blink::Platform::current() object has mocked resource load capabilities (see TestBlinkWebUnitTestSupport's use of WebURLLoaderMockFactory), then override ContentRendererClient::willSendRequest(), which is called just before each network request, to register a mock for that request. It looks like renderer_tree_fuzzer.cc is in content/test/? If so, it should be able to set a custom Platform implementation blink::Platform::initialize().

@mmoroz, bouncing back to you. Let me know if you need any additional help or guidance in getting things wired up, or if neither of those ideas will work for some reason.

Thanks a lot for the ideas, japhet@!

To be honest, I need a guidance in finding an owner for this issue ;)

Fuzz targets (i.e. fuzzers) are similar to unit tests, so we (security team working on fuzz infrastructure & dynamic tools working on fuzzing instruments) cannot support and fix all of them by ourselves. Fuzz targets should be owned and maintained by developers.

ClusterFuzz has detected this issue as fixed in range 455109:455254.

Detailed report: https://cluster-fuzz.appspot.com/testcase?key=5337386156556288

Fuzzer: libfuzzer_renderer_tree_fuzzer
Job Type: libfuzzer_chrome_asan
Platform Id: linux

Crash Type: UNKNOWN READ
Crash Address: 0x000000000000
Crash State:
  content::WebURLLoaderImpl::Context::Start
  content::WebURLLoaderImpl::loadAsynchronously
  blink::ResourceLoader::start
  
Sanitizer: address (ASAN)

Regressed: https://cluster-fuzz.appspot.com/revisions?job=libfuzzer_chrome_asan&range=408165:408299
Fixed: https://cluster-fuzz.appspot.com/revisions?job=libfuzzer_chrome_asan&range=455109:455254

Reproducer Testcase: https://cluster-fuzz.appspot.com/download/AMIfv95IbJcKbLdaT2ELHs2Rfyfitz13aLn8K5uuxJqYE_MSpErfCo9M59V93xY_3UDUd8Qb1_M-AuJW7tA1ppuxysIq1UXrSC0l36rlANyRS8J6Cg_RVbNAGx_A3qazt9qazjy8gYqbOgKQs-BZ_hnksHg7yEKAmowNmsZ2cK3eSFyMvVQnABbwgsDVGOD4a28kSUcDR9l3DJy0Kyf-n4wLbHVbr09TFopNB6nIKIh65J7x6q-QC7o_EwktVpahd0TK6jkBPY_xiyy2JlwnxUCkXepgm0saH1qg21h8NRlw9tDrwfy8Q161mJBRmQV3xnEeOEhzWwCMMPXulY23_J8FSkdDJmGFfmGcwhHVd_CgrXfL4baDGcA?testcase_id=5337386156556288


See https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reproducing.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 5337386156556288 is verified as fixed, so closing issue.

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

 Issue 704172  has been merged into this issue.