Heap-use-after-free in mojo::BindingSetBase<content::mojom::PushMessaging, mojo::Binding<content::mojom |
|||||||||||||||
Issue descriptionDetailed report: https://clusterfuzz.com/testcase?key=6128772353622016 Fuzzer: inferno_webbot Job Type: linux_asan_chrome_chromeos Platform Id: linux Crash Type: Heap-use-after-free READ 8 Crash Address: 0x6140000fd178 Crash State: mojo::BindingSetBase<content::mojom::PushMessaging, mojo::Binding<content::mojom content::PushMessagingManager::BindRequest base::internal::Invoker<base::internal::BindState<void Sanitizer: address (ASAN) Recommended Security Severity: High Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=6128772353622016 Additional requirements: Requires Gestures Issue filed automatically. See https://github.com/google/clusterfuzz-tools 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.
,
Mar 3 2018
Automatically applying components based on crash stacktrace and information from OWNERS files. If this is incorrect, please apply the Test-Predator-Wrong-Components label.
,
Mar 3 2018
,
Mar 5 2018
Peter, can you please have a look at this and help with an owner? I think this is related to a recent CL by johnme@, but apparently he is no longer working on Chrome. https://chromium.googlesource.com/chromium/src/+/3589edc60b2bf8fcd59abafa3a622bce05ecc368 Cluster-fuzz is hitting this crash repeatedly but can't reproduce consistently with any given test case, which I think is because it is a threading issue. The report is a use-after-free where the mojo BindingSet has been destroyed, which possibly implies a race between a binding request and object destruction?
,
Mar 5 2018
Oh sorry, that was not a recent CL, I don't know how far back this crash goes.
,
Mar 5 2018
,
Mar 7 2018
,
Mar 17 2018
peter: 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
,
Mar 22 2018
binding_set.h:281 is the first local data read for a call to PushMessagingManager::BindRequest(), so it looks like the call's being made on a released instance. The interface is being added to the registry here: https://cs.chromium.org/chromium/src/content/browser/renderer_host/render_process_host_impl.cc?sq=package:chromium&dr=CSs&l=1962 registry->AddInterface( base::Bind(&PushMessagingManager::BindRequest, base::Unretained(push_messaging_manager_.get()))); Is it possible for the registry to outlive the RenderProcessHostImpl instance? I see lots of other interfaces being added in RenderProcessHostImpl::RegisterMojoInterfaces() that also assume it won't. The memory model of PushMessagingManager exactly matches that of the GpuClient, so presumably we would be seeing crashes there too?
,
Mar 30 2018
CC'ing more folks to take a look at c#9. peter@, please take a look at this once you're back from OOO.
,
Mar 30 2018
mmoroz@ - am I meant to be cc'd? Not familiar with push API (I'm media/), but let me know if I can be helpful.
,
Apr 5 2018
peter: 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
,
Apr 11 2018
Security Sheriff Ping: Any updates on this one, this is a high severity security bug, and it looks like there hasn't been any activity in more than a week.
,
Apr 18 2018
,
Apr 18 2018
Security Sheriff ping -- this is a high severity bug that's going to Stable. peter@ -- can you please prioritize this? Thanks. If you need any help from any other team/person, be sure to let me know and I'll get their attention here.
,
Apr 28 2018
,
May 2 2018
We commit ourselves to a 60 day deadline for fixing for high severity vulnerabilities, and have exceeded it here. If you're unable to look into this soon, could you please find another owner or remove yourself so that this gets back into the security triage queue? For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 15 2018
ClusterFuzz testcase 6128772353622016 is flaky and no longer crashes, so closing issue. If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.
,
Aug 21
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 ClusterFuzz
, Mar 3 2018