Automatically adding ccs based on OWNERS file / target commit history.

If this is incorrect, please add ClusterFuzz-Wrong label.

The crash site is caused by LOG(FATAL):

  if (!command.ParseFromArray(buffer.data(), bytes)) 
    LOG(FATAL) << "error parsing protobuf";

@kerrnel, it looks like we can just use LOG(ERROR) here and return without sending a response? Since the server process waits the response with a timeout of 2s.

Crashing on LOG(FATAL) should be fine since it's a deliberate crash, right? That's the way the model works. If some invalid input is received, the helper process crashes and then the main process will exit.

Sounds reasonable. 

Is there a way to not report LOG(FATAL) in ClusterFuzz?

I think marking this bug as WontFix would prevent ClusterFuzz from annoying you. But there will still be a problem.

libFuzzer/CF doesn't handle exiting well, since libFuzzer runs in-process.

As you can see here, the fuzzer isn't doing much because of these exits. 
https://clusterfuzz.com/fuzzer-stats/by-day/date-start/2018-11-13/date-end/2018-11-19/fuzzer/libFuzzer_chromeos_imageloader_helper_process_receiver_fuzzer/job/libfuzzer_asan_chromeos

It would be nice if we didn't need to exit the process on invalid input.

Will libFuzzer/CF handle LOG(FATAL) better in the future? 

It looks like many system services in src/platform2/ uses LOG(FATAL) here and there: https://cs.corp.google.com/search/?q=%22LOG(FATAL)%22+file:%5Esrc/platform2/+package:%5Echromeos_public$&det=none&type=cs

Because this is a privileged helper process that should only be receiving valid input from the main process, I think the most sensible course of action is to LOG(FATAL) on an invalid input. It should be an "impossible" condition so it's not safe to try and keep executing.

One possible workaround is to detect this case in llvmFuzzerTestOneInput function() and just do an early return.

some code uses FATAL when they want a shorthand for LOG(ERROR);exit and they don't realize FATAL triggers an abort/crash report.  that said, that's not what we're talking about here.

for the purpose of fuzzing, i think it's fine to add a protected method that does the bulk of the work and returns true/false, and OnFileCanReadWithoutBlocking calls that and takes care of exiting/aborting.  that way the fuzzer can call the internal func and not worry about it exiting.

Yes I think vapier@ has a good suggestion. Allow the "public code" to exit/abort as it wishes, but have internal functions that fuzzer can call.

The only way to avoid that branch being hit is to provide a serialized protobuf message which needs libprotobuf-mutator to work.

The internal functions will basically takes a serialized protobuf message to work on which again requires libprotobuf-mutator...

I'm marking this as won't fix and we use crbug.com/904593 to track using libprotobuf-mutator.

ClusterFuzz testcase 5200048113319936 is still reproducing on tip-of-tree build (trunk).

If this testcase was not reproducible locally or unworkable, ignore this notification and we will file another bug soon with hopefully a better and workable testcase.

Otherwise, if this is not intended to be fixed (e.g. this is an intentional crash), please add ClusterFuzz-Ignore label to prevent future bug filing with similar crash stacktrace.

ClusterFuzz testcase 5200048113319936 appears to be flaky, updating reproducibility label.