Predator and CL did not provide any possible suspects.
Using Code Search for the file, "host_resolver_proc.cc" assigning to concern owner from GIT Blame.

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

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

Thanks!  Will do.

Pretty sure this is a real bug, but applies only to the IPv6 IP "::".

https://chromium-review.googlesource.com/578168 caught it, but https://chromium-review.googlesource.com/569298 broke it, but even before that, we were needlessly sending the "::" address to GetAddrInfo, instead of resolving is synchronously, like we do for other IPv6 IPs.

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

commit 3ac004d5921840187883c331e161fb3bc5ae880f
Author: Matt Menke <mmenke@chromium.org>
Date: Fri Jul 21 23:41:15 2017

Fix MockHostResolver calling system resolver with invalid DNS values.

HostResolverImpl used to pass all non-numeric host names it received,
including invalid ones, to the system HostResolver. That was changed
in https://chromium-review.googlesource.com/569298 (Since the bad
addresses could be sent over the wire with the async resolver, and
it generally seemed like a bad idea).  And all was right with the world.

Then a DCHECK was added to SystemHostResolverCall for invalid hostnames,
since it should no longer be called with them in production. However,
it turns out the MockHostResolver calls that method directly, bypassing
HostResolverImpl, and does so with IPv6 host names (Or whatever other
stuff is passed to it). In particular, the socks_client_socket_fuzzer
does this by passing in "::1".  This is a legal use of the
MockHostResolver API, not a bug in the fuzzer.  So this CL modifies
MockHostResolver not to do that.

Bug:  747243 
Change-Id: Ib4be76f1d03f33bc65a493ac73aae6407ca3383d
Reviewed-on: https://chromium-review.googlesource.com/581788
Commit-Queue: Matt Menke <mmenke@chromium.org>
Reviewed-by: Eric Roman <eroman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#488800}
[modify] https://crrev.com/3ac004d5921840187883c331e161fb3bc5ae880f/net/dns/mock_host_resolver.cc
[modify] https://crrev.com/3ac004d5921840187883c331e161fb3bc5ae880f/net/dns/mock_host_resolver.h

Turns out this was not a real bug, just a test issue, so no need to merge the fix.

ClusterFuzz has detected this issue as fixed in range 488742:488823.

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

Fuzzer: libFuzzer_net_socks_client_socket_fuzzer
Job Type: libfuzzer_chrome_asan_debug
Platform Id: linux

Crash Type: CHECK failure
Crash Address: 
Crash State:
  IsValidDNSDomain(host) in host_resolver_proc.cc
  base::debug::DebugBreak
  net::SystemHostResolverCall
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan_debug&range=488313:488426
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan_debug&range=488742:488823

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


See https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reproducing.md 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 6159549412409344 is verified as fixed, so closing issue as verified.

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