Automatically applying components based on crash stacktrace and information from OWNERS files.

If this is incorrect, please apply the Test-Predator-Wrong-Components label.

Unable to find actual suspect through code search and also from the provided CL under regression range, hence adding appropriate label and leaving it as untriaged for further updates.

Thanks!

I have confirmed my suspicion: this timeout can be fixed by imposing RFC 1034's domain name length limit in DnsRecordParser::ReadName().

At first I couldn't reproduce this with the instructions provided by clusterfuzz. I'm guessing my machine is too fast; reducing the timeout from 25 to 5 did the trick!

On my machine, the size of the string produced by DnsRecordParser::ReadName() gets up to ~5600 before the 5 second mark. Given the 255-octet limit from RFC 1034, we theoretically can abort early and stop this nonsense. Since theory != practice, we are playing it safe and waiting on data from the UMA metric Net.DNS.RecordParser.DomainNameLength to see if we can set a sensible limit. In the meantime, I'm working on a CL.

The command to reproduce:
  /google/data/ro/teams/clusterfuzz-tools/releases/clusterfuzz reproduce 5719826555994112 --current --skip-deps --target-args="-timeout=5"

Alright, we have about 14e9 UMA samples from the Canary channel. Not one of the domain names we parsed in the wild had a length >= 135 octets. I believe it is safe to impose the 255-octet limit specified by RFC 1034.

David, do you think we should wait for data from Stable?

Link to the UMA metric: https://uma.googleplex.com/p/chrome/histograms/?endDate=20181208&dayCount=7&histograms=Net.DNS.RecordParser.DomainNameLength&fixupData=true&showMax=true&filters=channel%2Ceq%2C1%2Cisofficial%2Ceq%2CTrue&implicitFilters=isofficial

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

commit 51d2955b1738b6b963f9b7478b3446b956413292
Author: Daniel McArdle <dmcardle@chromium.org>
Date: Fri Dec 14 19:00:37 2018

Enforce maximum domain name length in DNS response parser

Bug:  811618 
Change-Id: I57dc54e56e3a857f05b34dffdefcec634719e0d6
Reviewed-on: https://chromium-review.googlesource.com/c/1369638
Reviewed-by: Eric Orth <ericorth@chromium.org>
Commit-Queue: Daniel McArdle <dmcardle@chromium.org>
Cr-Commit-Position: refs/heads/master@{#616771}
[modify] https://crrev.com/51d2955b1738b6b963f9b7478b3446b956413292/net/dns/dns_record_fuzzer.cc
[modify] https://crrev.com/51d2955b1738b6b963f9b7478b3446b956413292/net/dns/dns_response.cc
[modify] https://crrev.com/51d2955b1738b6b963f9b7478b3446b956413292/net/dns/dns_response_unittest.cc

That does it! We no longer parse domain names in DNS responses that exceed 255 octets. This particular test case should no longer cause timeouts in net_dns_record_fuzzer.

ClusterFuzz has detected this issue as fixed in range 616770:616772.

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

Fuzzer: libFuzzer_net_dns_record_fuzzer
Fuzz target binary: net_dns_record_fuzzer
Job Type: libfuzzer_chrome_asan
Platform Id: linux

Crash Type: Timeout (exceeds 25 secs)
Crash Address: 
Crash State:
  net_dns_record_fuzzer
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan&range=452851:452972
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan&range=616770:616772

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

See https://github.com/google/clusterfuzz-tools for instructions to reproduce this bug locally.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.