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

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

Automatically assigning owner based on suspected regression changelist https://chromium.googlesource.com/chromium/src/+/4dfa217e969e2720e6f0281d5007aa9ffb92d940 (Add proxy look up API to NetworkContexts, convert PPAPI consumers.).

If this is incorrect, please let us know why and apply the Test-Predator-Wrong-CLs label. If you aren't the correct owner for this issue, please unassign yourself as soon as possible so it can be re-triaged.

The issue is almost certainly how mojo is used in refcounting - our last reference is lost on the IO thread, we post a task to delete the object, and then a mojo call comes in on the UI thread, and we try to send an IPC message...which adds a ref again, so then we have both a posted delete task and a non-zero reference count, which isn't good.  Fix should be trivial, though.

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

(This is just about the last CL I send you two, which you've both already signed off on)

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

commit 5491b007536cc28a362643d9c27bbb0080959091
Author: Matt Menke <mmenke@chromium.org>
Date: Mon Aug 06 18:46:01 2018

Fix double-delete in ResolveProxyMsgHelper.

The class is reference counted, and makes a mojo call, with a callback,
on the UI thread. The callback was passed a raw pointer to the class,
but when it was invoked, it grabbed a reference to the class. When the
class's last reference is released, it posts a delete task to the UI
thread.

So if the class's last reference was released, and then it received a
a Mojo callback, there would be a pending delete task, we'd grab a
new ref (Increasing the refcount from 0 to 1), the delete task would
run, and then a new delete task would be posted when the reference went
to 0 again, resulting in a double-delete.

This CL fixes that by making the class keep a reference to itself
whebever there's a pending mojo callback. MessageFilters are designed
to be able to call Send() after the class they want to send messages
to has been deleted, so the increased lifetime is completely safe.

Bug:  870675 
Change-Id: I64f6656e61dc9222a67cd40555d3dd73fb48e208
Reviewed-on: https://chromium-review.googlesource.com/1161967
Commit-Queue: Matt Menke <mmenke@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Eric Roman <eroman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#580932}
[modify] https://crrev.com/5491b007536cc28a362643d9c27bbb0080959091/content/browser/resolve_proxy_msg_helper.cc
[modify] https://crrev.com/5491b007536cc28a362643d9c27bbb0080959091/content/browser/resolve_proxy_msg_helper.h
[modify] https://crrev.com/5491b007536cc28a362643d9c27bbb0080959091/content/browser/resolve_proxy_msg_helper_unittest.cc

ClusterFuzz has detected this issue as fixed in range 580931:580932.

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

Fuzzer: ipc_fuzzer_mut
Job Type: linux_asan_chrome_ipc
Platform Id: linux

Crash Type: Heap-use-after-free READ 8
Crash Address: 0x612000230600
Crash State:
  base::DeleteHelper<content::ResolveProxyMsgHelper>::DoDelete
  base::debug::TaskAnnotator::RunTask
  base::MessageLoop::RunTask
  
Sanitizer: address (ASAN)

Recommended Security Severity: High

Regressed: https://clusterfuzz.com/revisions?job=linux_asan_chrome_ipc&range=580186:580200
Fixed: https://clusterfuzz.com/revisions?job=linux_asan_chrome_ipc&range=580931:580932

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

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 5075130913652736 is verified as fixed, so closing issue as verified.

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

This bug requires manual review: M69 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), kariahda@(iOS), cindyb@(ChromeOS), govind@(Desktop)

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

HAve no idea why that label was applied - the CL with the regression is https://chromium-review.googlesource.com/c/chromium/src/+/1136875, which I landed August 2nd.  M69 branched on July 19th.

Rejecting merge to M69 based on comment #16.

+awhalley@ & mbarbella@, PTAL comment #16.

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