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

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

This is a serious security regression. If you are not able to fix this quickly, please revert the change that introduced it.

If this doesn't affect a release branch, or has not been properly classified for severity, please update the Security_Impact or Security_Severity labels, and remove the ReleaseBlock label. To disable this altogether, apply ReleaseBlock-NA.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Hey Brett, could you quickly rule out whether this might be an artifact of your conversion from std:: to base:: queues a few weeks ago?  The CF regression range isn't always reliable.

For example, were there cases where we'd formerly get away with pop'ing an empty container or some such that are now hit in base's implmentations? Thanks.

The empty container thing does come to mind. Does this build run DCHECKs? This code path will DCHECK if it's an empty container. If we do run DCHECKs that would imply that the container is not empty.

Popping a empty std::deque is undefined, so it's possible this worked before without anybody noticing. The circular_deque implementation will definitely do bad things if you do this.

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.

[Bulk Edit]
URGENT - PTAL.
M63 Stable promotion is coming soon and your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP. Thank you.

ClusterFuzz has detected this issue as fixed in range 512849:512869.

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

Fuzzer: libFuzzer_net_host_resolver_impl_fuzzer
Job Type: libfuzzer_chrome_msan
Platform Id: linux

Crash Type: Use-of-uninitialized-value
Crash Address: 
Crash State:
  void base::internal::VectorBuffer<std::__1::basic_string<char, std::__1::char_tr
  base::circular_deque<std::__1::basic_string<char, std::__1::char_traits<char>, s
  net::DnsTransactionImpl::ProcessAttemptResult
  
Sanitizer: memory (MSAN)

Recommended Security Severity: Medium

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_msan&range=503775:503848
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_msan&range=512849:512869

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

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

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

This might be related to  issue 774854 .

Might this be related to issue 779589? If so it looks like  issue 761639  is already going to be merged to M63 - anything else might be worth merging?

Yeah, this is the exact same bug as  issue 774846 , it just looks different when msan finds it than it does when asan finds it. The CL I'm already merging is sufficient.

If anyone is wondering about the effect that the switch to circular_deque had, see  https://crbug.com/774846#c16 .

This bug is a great example of why I wanted fuzzer crash triage based on the component where the fuzzer lives: bugs found by this fuzzer are almost always DNS bugs, but this one took more than two weeks to get to me, despite being a release blocking security bug. And because it's a security bug, I couldn't have found it by looking at all of this fuzzer's bugs myself, I wouldn't have had the right permissions.

Thanks for the details mgersh@!

+ochang@ for the last ❡ of #15

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot