New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 2 users

Issue metadata

Status: Verified
Owner:
Closed: Dec 14
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Chrome , Mac
Pri: 1
Type: Bug

Blocked on:
issue 905823



Sign in to add a comment
link

Issue 811618: Timeout in net_dns_record_fuzzer

Reported by ClusterFuzz, Feb 13 2018 Project Member

Issue description

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

Fuzzer: libFuzzer_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

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

Issue filed automatically.

See https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reference.md for more information.
 

Comment 1 by ClusterFuzz, Feb 13 2018

Project Member
Components: Internals>Network>DNS
Labels: Test-Predator-Auto-Components
Automatically applying components based on crash stacktrace and information from OWNERS files.

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

Comment 2 by brajkumar@chromium.org, Feb 13 2018

Cc: brajkumar@chromium.org
Labels: M-64 Test-Predator-Wrong CF-NeedsTriage
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!

Comment 3 by ClusterFuzz, Mar 9 2018

Project Member
Labels: OS-Mac

Comment 4 by dmcardle@chromium.org, Nov 15

Blockedon: 905823

Comment 5 by dmcardle@chromium.org, Nov 30

Owner: dmcardle@chromium.org
Status: Assigned (was: Untriaged)

Comment 6 by manoranjanr@google.com, Dec 5

Labels: -CF-NeedsTriage

Comment 7 by dmcardle@chromium.org, Dec 5

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"

Comment 8 by ClusterFuzz, Dec 9

Project Member
Labels: OS-Chrome

Comment 9 by dmcardle@google.com, Dec 10

Cc: davidben@chromium.org
Status: Started (was: Assigned)
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?

Comment 11 by bugdroid1@chromium.org, Dec 14

Project Member
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

Comment 12 by dmcardle@google.com, Dec 14

Status: Verified (was: Started)
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.

Comment 13 by ClusterFuzz, Dec 15

Project Member
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.

Sign in to add a comment