Issue metadata
Sign in to add a comment
|
Heap-use-after-free in net::HttpCache::Transaction::DoCacheWriteResponse |
||||||||||||||||||||||
Issue descriptionDetailed report: https://clusterfuzz.com/testcase?key=5676238086340608 Fuzzer: attekett_dom_fuzzer Job Type: linux_asan_chrome_mp Platform Id: linux Crash Type: Heap-use-after-free READ 8 Crash Address: 0x60c00037d540 Crash State: net::HttpCache::Transaction::DoCacheWriteResponse net::HttpCache::Transaction::DoLoop net::HttpCache::ProcessEntryFailure Sanitizer: address (ASAN) Recommended Security Severity: High Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5676238086340608 Issue filed automatically. See https://github.com/google/clusterfuzz-tools for more information.
,
Aug 15
,
Aug 15
bnc: Assigning to you since you've been active on http_cache.cc (and since it looks like shivanisha is no longer working in Chrome), feel free to reassign if appropriate.
,
Aug 15
Changing status to "Assigned" since there is an owner. My experience is that Clusterfuzz has a relatively high false positive rate, so this bug might be automatically classified as solved and marked "Verified" within a few days. If that does not happen, I'll start by reproducing locally. While there is no narrow bisect range or culprit identified by Clusterfuzz, it seems like this regression has happened a very long time ago, so bisecting might not be the best approach: old checkouts might not compile, or code might have changed so much that whatever I find does not apply to tip of tree any longer. In any case, I'll see what I can do.
,
Aug 16
This crash is seen in the wild, there are currently 506 occurrences on the dashboard across all platforms and versions: https://crash.corp.google.com/browse?q=expanded_custom_data.ChromeCrashProto.magic_signature_1.name%3D%27net%3A%3AHttpCache%3A%3ACanTransactionWriteResponseHeaders%27
,
Aug 16
bnc@, if the testcase is flaky due to race condition, clusterfuzz can't do much to make it reliable. this seems like a case here. if you think clusterfuzz has false positive rates, then please send email to clusterfuzz-dev [at] google [dot] com and we will look at improving things.
,
Aug 30
bnc: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers? If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one? If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 5
,
Sep 13
ClusterFuzz has detected this issue as fixed in range 590940:590941. Detailed report: https://clusterfuzz.com/testcase?key=5676238086340608 Fuzzer: attekett_dom_fuzzer Job Type: linux_asan_chrome_mp Platform Id: linux Crash Type: Heap-use-after-free READ 8 Crash Address: 0x60c00037d540 Crash State: net::HttpCache::Transaction::DoCacheWriteResponse net::HttpCache::Transaction::DoLoop net::HttpCache::ProcessEntryFailure Sanitizer: address (ASAN) Recommended Security Severity: High Fixed: https://clusterfuzz.com/revisions?job=linux_asan_chrome_mp&range=590940:590941 Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5676238086340608 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.
,
Sep 13
ClusterFuzz testcase 5676238086340608 is verified as fixed, so closing issue as verified. If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.
,
Sep 13
,
Sep 15
,
Sep 15
This bug requires manual review: M70 has already been promoted to the beta branch, so this requires manual review Please contact the milestone owner if you have questions. Owners: benmason@(Android), kariahda@(iOS), geohsu@(ChromeOS), abdulsyed@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 18
,
Oct 3
There is no fix and this keeps coming back from time to time. ClusterFuzz can't do anything if the testcase is flaky. This is giving a stacktrace to work from. In most cases, we find reproducible bugs. If that is false, please email clusterfuzz-dev with a list of things you think were false positives. I do recommend taking a closer look since this is outside sandbox and is sec-critical.
,
Oct 4
bnc: Uh oh! This issue still open and hasn't been updated in the last 49 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers? If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one? If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 4
Please mark security bugs as fixed as soon as the fix lands, and before requesting merges. This update is based on the merge- labels applied to this issue. Please reopen if this update was incorrect. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 4
Marking as reward-na for now, see #15
,
Jan 10
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 |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by sheriffbot@chromium.org
, Aug 15