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

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

mmenke, could you please take a look at this, and point a better person at it if you're not the right person? Memory corruption in the browser process is uncomfortably exciting. :) Thank you!

This is a critical security issue. 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

[->shivanisha]:  Shivani, mind taking a look?  ThrottlingNetworkTransaction was recently renamed and over to the network service, so this could theoretically be a bug there, but the regression timeling and the trace make me think it may be related to work improving the cache, particularly https://chromium-review.googlesource.com/684615

Taking a look.

My asan build is still in progress but what I think is happening is this: 2 cache transactions are sharing the network transaction and the 1st one that created the network transaction is destroyed first and then the second is destroyed. This is when ~HttpNetworkTransaction is invoked. If no Read() has been invoked till this point then HNT::request_ would still be non-null and would be accessed in ~HttpNetworkTransaction but its already freed when the 1st cache transaction was destroyed.
Wondering if it is possible to move the assignment of null to request_ from line 328 in HNT::Read() to https://cs.chromium.org/chromium/src/net/http/http_network_transaction.cc?sq=package:chromium&l=1335

Actually, ~HttpNetworkTransaction should not be doing the work of resetting callbacks in request_->upload_data_stream as it is owned by URLRequest and should be done in ~URLRequest. 
https://codereview.chromium.org/2330983002 already removes plumbing of upload data stream . This will further clean it up.

Uploaded a fix for review:
https://chromium-review.googlesource.com/c/chromium/src/+/747507

Actually, a better fix is here:
https://chromium-review.googlesource.com/c/chromium/src/+/749523

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

commit fdcaefd0639d83fb7fcf78888b72ff474b9e4eda
Author: Shivani Sharma <shivanisha@chromium.org>
Date: Thu Nov 02 00:12:26 2017

Reset request_ at the end of HttpNetworkTransaction::Start instead of in Read.

Bug:  779919 
Cq-Include-Trybots: master.tryserver.chromium.android:android_cronet_tester;master.tryserver.chromium.mac:ios-simulator-cronet
Change-Id: I30a0a94731a4a927b0c5882f3e4384adc886543c
Reviewed-on: https://chromium-review.googlesource.com/749523
Commit-Queue: Shivani Sharma <shivanisha@chromium.org>
Reviewed-by: Matt Menke <mmenke@chromium.org>
Cr-Commit-Position: refs/heads/master@{#513328}
[modify] https://crrev.com/fdcaefd0639d83fb7fcf78888b72ff474b9e4eda/net/http/http_network_transaction.cc
[modify] https://crrev.com/fdcaefd0639d83fb7fcf78888b72ff474b9e4eda/net/http/http_network_transaction_unittest.cc

ClusterFuzz has detected this issue as fixed in range 513290:513496.

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

Fuzzer: attekett_dom_fuzzer
Job Type: mac_asan_chrome
Platform Id: mac

Crash Type: Heap-use-after-free READ 8
Crash Address: 0x619000dbea00
Crash State:
  net::HttpNetworkTransaction::~HttpNetworkTransaction
  net::HttpNetworkTransaction::~HttpNetworkTransaction
  content::ThrottlingNetworkTransaction::~ThrottlingNetworkTransaction
  
Sanitizer: address (ASAN)

Recommended Security Severity: Critical

Regressed: https://clusterfuzz.com/revisions?job=mac_asan_chrome&range=512479:512492
Fixed: https://clusterfuzz.com/revisions?job=mac_asan_chrome&range=513290:513496

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

See https://github.com/google/clusterfuzz-tools 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 4854253498925056 is verified as fixed, so closing issue as verified.

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

does anything here need a merge?

Cluserfuzz claims it both regressed and fixed in 64, so no as long as that's accurate.

I'm afraid this is also reward-0 since it was hit by an internal fuzzer (ochang_search_index_mutator) within the same day.

What does reward-0 imply?

I think awhalley may have been responding on the wrong bug?  I'm pretty sure that when Cluserfuzz reports a bug, it isn't eligible for a reward, poor thing.

We are reporting on the right bug. we are running an external fuzzer from attekett on clusterfuzz, so it is eligible for rewards when it finds a new bug. in this case, our own fuzzer also hit this regression, so that is why 0 reward.

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