CHECK failure: !first_party_url_.is_empty() in appcache_host.cc |
|||||||
Issue descriptionDetailed report: https://clusterfuzz.com/testcase?key=4514780016279552 Fuzzer: libFuzzer_appcache_fuzzer Job Type: libfuzzer_chrome_asan_debug Platform Id: linux Crash Type: CHECK failure Crash Address: Crash State: !first_party_url_.is_empty() in appcache_host.cc content::AppCacheHost::SelectCache content::AppCacheBackendImpl::SelectCache Sanitizer: address (ASAN) Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=4514780016279552 Issue filed automatically. See https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reference.md for more information. Note: This crash might not be reproducible with the provided testcase. That said, for the past 14 days we've been seeing this crash frequently. If you are unable to reproduce this, please try a speculative fix based on the crash stacktrace in the report. The fix can be verified by looking at the crash statistics in the report, a day after the fix is deployed. We will auto-close the bug if the crash is not seen for 14 days.
,
Dec 1
Automatically adding ccs based on OWNERS file / target commit history. If this is incorrect, please add ClusterFuzz-Wrong label.
,
Dec 2
,
Dec 2
,
Dec 5
Unable to provide possible suspect using predator, CL and Code Search. Could someone please look into the issue. Thanks...
,
Dec 7
Are we certain that the fuzzer calls AppCacheHost::CreateRequestHandler before any AppCacheHost::SelectCache calls are made? If not that would produce this crash. It could be that the fuzzer doesn't maintain the same invariants as the real code.
,
Dec 7
,
Dec 7
FWIW, I don't think we should trust the renderer to make the right calls. If this comes down to the wrong call sequence, the browser should deny the call / terminate the renderer. The duplicated bug shows the DCHECK fires in production, so the browser code has is a real bug somewhere.
,
Dec 8
Yes, Victor is totally right in c#8. When fuzzing the browser-side code, we should never trust the renderer. That's how nedwill@ made a sandbox escape out of one of the AppCache bugs, which combined with a renderer code execution led to a full chain exploit.
,
Dec 8
Yeah perhaps the renderer can be killed and we return early in this case? It should be handled though since the renderer can do anything when compromised and we don't want to hide a vulnerability behind this assumption. |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by ClusterFuzz
, Dec 1Labels: Test-Predator-Auto-Components