Using the provided regression range assigning to the possible suspect as per the change made for the file, “spdy_session.cc”
Suspecting Commit#
https://chromium.googlesource.com/chromium/src/+/0ef1556e374c51f1ffc344e88cb1d9e6659b03a2

@bnc -- Could you please look into this issue, kindly reassign if it has nothing to do with your changes.

Looking at the stack trace, it seems like CanPool() is called with an |ssl_info| argument that has no |cert|.  This is because in spdy_session_fuzzer.cc, in LLVMFuzzerTestOneInput, ImportCertFromFile() does not find the cert file and returns a null scoped_refptr<>.  The reason for this is that the cert file is in the source tree.  GetTestCertsDirectory() returns an absolute path for the cert file directory.

If, however, there is no source checkout available on the machine that runs the fuzz test, then the test fails.  I can reproduce this locally.

Tagging with libFuzzer component and cc-ing some folks who are active on other libFuzzer bugs for visibility.  I hope this can be fixed by somehow providing the necessary cert file on the fuzzing machines, because https://crrev.com/c/558146 was a neat simplification to production code, and it would be somewhat error-prone to revert it just to special-case fuzzing in SpdySession.

Is it possible to import |cert| from memory? For example, like the following: https://cs.chromium.org/chromium/src/third_party/boringssl/src/fuzz/ssl_ctx_api.cc?l=212 ?

Sure that sounds like a great idea, let me try that.

Note: We really don't want to check certs in on files to import from memory - that's created a number of challenges for maintaining and updating those certs.

If we do need to go down that route, it'd be good to have it integrated/done by the build system, so that the canonical file is and remains what's in the source tree. My understanding is iOS does something similar (with respect to needing to bundle files), but just making sure the approach is done through generation rather than static checkins.

I uploaded https://crrev.com/c/760488 but I'm not in love with it to say at least.  I am looking at testing/libfuzzer/fuzzer_test.gni, it should be fairly easy to add an attribute to fuzzer_test that would specify files that need to be copied for the fuzzer to work.  I'll give it a shot.

At the same time, how can I programmatically access the $root_build_dir path from spdy_session_fuzzer.cc?

Looking at https://cs.chromium.org/chromium/src/third_party/libFuzzer/src/standalone/StandaloneFuzzTargetMain.c?l=37 and at https://cs.chromium.org/chromium/src/testing/libfuzzer/unittest_main.cc?l=54, I get the impression that libfuzzer_main gets all its input through command line arguments.  It might not be easy to get a hold of that directory.  I see that the fuzzer binary is launched from another directory, so base::GetCurrentDirectory() would not work, and I do not see any function in base/files/file_util.h that would return the directory of the executable object.

bnc: My suggestion (for something like comment #6) would be that if we have the build system generate a .inc file from the checked in cert, and then have that file as part of the build. Apologies for not being more precise there.

It seems like that solution may best balance the needs to have the file deterministically part of the fuzzer, while still allowing greater flexibility in maintaining and updating that file with existing tools (check in a new cert file, and the build system will regenerate the .inc)

Doing that would just require a generator to convert a cert into a header file. Is that something that seems reasonable?

Auto-generated .inc file included in the build SGTM!

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

commit 9d72b93a1d661c092c883db10baa2181269dfafc
Author: Bence Béky <bnc@chromium.org>
Date: Wed Nov 15 00:53:53 2017

Bundle test certificate in fuzzer at compile time.

net_spdy_session_fuzzer is run on machines where source checkout is not
available, therefore test certificates cannot be read from the usual
location.  One possible way to solve this is to read in the certificate
at compile time as a static resource.

Bug:  781846 
Cq-Include-Trybots: master.tryserver.chromium.android:android_cronet_tester;master.tryserver.chromium.mac:ios-simulator-cronet
Change-Id: I31d03bc88ac9652551f1e08f944e113eb63c7bd8
Reviewed-on: https://chromium-review.googlesource.com/760488
Commit-Queue: Bence Béky <bnc@chromium.org>
Reviewed-by: Eric Roman <eroman@chromium.org>
Reviewed-by: Ryan Sleevi <rsleevi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#516530}
[modify] https://crrev.com/9d72b93a1d661c092c883db10baa2181269dfafc/net/BUILD.gn
[add] https://crrev.com/9d72b93a1d661c092c883db10baa2181269dfafc/net/data/ssl/certificates/BUILD.gn
[add] https://crrev.com/9d72b93a1d661c092c883db10baa2181269dfafc/net/data/ssl/scripts/generate-spdy-session-fuzzer-includes.py
[modify] https://crrev.com/9d72b93a1d661c092c883db10baa2181269dfafc/net/spdy/chromium/spdy_session_fuzzer.cc

ClusterFuzz has detected this issue as fixed in range 516518:516544.

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

Fuzzer: libFuzzer_net_spdy_session_fuzzer
Job Type: libfuzzer_chrome_asan
Platform Id: linux

Crash Type: Null-dereference READ
Crash Address: 0x0000000001b0
Crash State:
  net::X509Certificate::GetSubjectAltName
  net::X509Certificate::VerifyNameMatch
  net::SpdySession::CanPool
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan&range=483710:483854
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan&range=516518:516544

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

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

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