Stack-overflow, Out of memory and Timeout issues are 'P2'.

Predator and CL could not provide any possible suspects.
Using the fuzzer file, "libxml_xml_read_memory_fuzzer" assigning to the concern owner who might be related.

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

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

This bug is fixed with http://crosreview.com/720537 which disables XML_PARSE_HUGE flag.

This input seems to have an entity reference loop.  By disabling the HUGE flag, libxml will detect the loop after 40 iterations and abort processing.

I will leave this bug open for now, because I expect it should be closed automatically by clusterfuzz.

Looking at the crash stats, it seems that this crash is still happening :( https://clusterfuzz.com/v2/crash-stats?block=day&days=7&end=418990&fuzzer=libFuzzer_libxml_xml_read_memory_fuzzer&group=platform&number=count&sort=total_count

I see about 75 timeout failures for the most recent day (Oct 18 to 19).  Are these all using the same input as the detailed report for this bug?  Is it possible to see what inputs are being used?

These crashes happen with different inputs. Unfortunately, I don't think that we preserve all those inputs.

As a potential solution to gather more "crashy" inputs, I can suggest you to download existing corpus:

$ mkdir corpus
$ gsutil -m rsync gs://https://pantheon.corp.google.com/storage/browser/clusterfuzz-corpus/libfuzzer/libxml_xml_read_memory_fuzzer corpus

and then run the fuzzer in the following way:

$ ./libxml_xml_read_memory_fuzzer -timeout=25 -print_final_stats=1 -jobs=20 -workers=20 ./corpus


It would spawn 20 fuzzer processes. I suspect that all of them will crash with a timeout after some time.

For more information, please see https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reference.md.

The link referenced in the description is no longer valid.

The timeouts are caused when libxml is trying to load external entities from stdin.  This happens when XML looks like:
  <!DOCTYPE xxx SYSTEM "-">
The dash ("-") is interpreted as a URI referring to stdin.

The fix for this is to disallow a number of libxml flags which can cause external entities to be loaded from stdin.
XML_PARSE_NOENT
XML_PARSE_DTDLOAD
XML_PARSE_DTDATT
XML_PARSE_DTDVALID

Within the chromium codebase, we do actually set the XML_PARSE_NOENT flag within XMLDocumentParser.
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/xml/parser/XMLDocumentParser.cpp?l=693&rcl=21d649e432bfbe852b91fb16efeff2abff94590d

First introduced in
https://chromium.googlesource.com/chromium/src/+/fedfc2c205c38d7a0f0abe1c3c3fce1c939b0bdb

So it is not ideal to be running fuzzer and disallowing the XML_PARSE_NOENT flag which is set in prod, however I can't think of a better solution.

In terms of risk in chromium that malformed XML could trigger reading from stdin, I don't believe there is any problem, but I'm not so familiar with all the code.

Chromium seems to only call libxml function xmlParseChunk.  It doesn't look like it ever has a codepath which calls to xmlSAX2ResolveEntity which leads to the code that can read from stdin.

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

commit d71658e30a9d55fb71f4afe9312d63db08e218c1
Author: Joel Hockey <joelhockey@chromium.org>
Date: Fri Oct 27 16:14:29 2017

Fix libxml fuzz timeouts when external entities read from stdin.

libxml reads from stdin when an external entity references
URL "-".  e.g.  <!DOCTYPE xxx SYSTEM "-">

This can be fixed by disallowing flags:
XML_PARSE_NOENT
XML_PARSE_DTDLOAD
XML_PARSE_DTDATTR
XML_PARSE_DTDVALID

BUG= 755142 

Change-Id: I7c4dff1544830972cde05cc6fecf3a792f47e83f
Reviewed-on: https://chromium-review.googlesource.com/741282
Reviewed-by: Max Moroz <mmoroz@chromium.org>
Commit-Queue: Max Moroz <mmoroz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#512193}
[modify] https://crrev.com/d71658e30a9d55fb71f4afe9312d63db08e218c1/testing/libfuzzer/fuzzers/libxml_xml_read_memory_fuzzer.cc

As per crash stats on https://clusterfuzz.com/v2/testcase-detail/4925550597767168?noredirect=1, the crash still occurs 60-80 times per day :(

We are closing all ooms and timeouts that are unreproducible. We won't be filing such bugs in future.