Predator could not provide any possible suspects.
Assigning to concern owner from CL --
https://chromium.googlesource.com/chromium/src/+log/e8e86350bdeace853f546c7040555c1fd1701029..dbb3de060b8c772ece2941b113b417a8d2d72d8e?pretty=fuller&n=10000

Suspecting Commit#
https://chromium.googlesource.com/chromium/src/+/82027ff5dafbb3fbafe44fede998a33667ea2bd1

@bcwhite -- Could you please look into the issue, kindly re-assign if this is not related to your changes.
Thank You.

There are explicit CHECKs to ensure that code does not create the same histogram name but with different types or parameters because that'll cause confusion or possibly crashes in other places later on.

This appears to the be the case of the Renderer sending an IPC to create a histogram of a name that already exists but with a different type.

In this way, a compromised Renderer could crash the browser.

Alexei, do we want to harden this?  It would involve going through all the histogram code and changing CHECKs into NOTREACHED/handler pairs.

I think the correct behaviour in this case would be to kill the renderer using the bad_message mechanism. We'd need a way to plumb that through, though.

However, I think there's two issues here:
  1. Is what we should do instead of CHECK in this case.
  2. What bug did clusterfuzz discover that caused the bad type to be sent?

I propose we file a separate bug for 1. and this bug could continue to track 2 - which I think needs investigation separately.

My understanding is that clusterfuzz was sending manufactured IPC messages to the browser as any compromised renderer could do.

Ah, I see - in that case just having this bug open to track the work for (1) should be sufficient.

However, since this is a CHECK - which would be treated as a crash and wouldn't be a security issue, I don't think P1 is correct for this. Changing to P3.

As for what to do...  I don't think we can do anything different at the only point of detection because anything other than a crash will lead to a histogram of an unexpected type/configuration being used later on.  Other CHECKs is the code may expect a certain configuration.

Can we just skip that record and kill the renderer?

Anyway, we can discuss more in person.

The caller in this could examine the return for null and act appropriately.  But this method is called for all histogram construction so returning null in the general case of an error is perhaps not acceptable as the eventual crash would be far away from the location creating the bad histogram.

Automatically applying components based on information from OWNERS files. If this seems incorrect, please apply the Test-Predator-Wrong-Components label.

ClusterFuzz has detected this issue as fixed in range 508393:508498.

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

Fuzzer: ipc_fuzzer_mut
Job Type: linux_asan_chrome_ipc
Platform Id: linux

Crash Type: CHECK failure
Crash Address: 
Crash State:
  histogram_type_ == histogram->GetHistogramType() in histogram.cc
  base::Histogram::Factory::Build
  base::LinearHistogram::DeserializeInfoImpl
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=linux_asan_chrome_ipc&range=495992:496058
Fixed: https://clusterfuzz.com/revisions?job=linux_asan_chrome_ipc&range=508393:508498

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

See https://github.com/google/clusterfuzz-tools 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 5738562573303808 is verified as fixed, so closing issue as verified.

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