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

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

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

timbrown@: Clusterfuzz has found an OOB read regression related to libappindicator. This might be caused by one of your CLs having stuck and the other having been reverted, but can you PTAL? Thanks!

There will likely be a merge required to address this because M66 branched in the meantime.

The use of libappindicator should be in a stable state.

My suspicion is that this issue always existed. However we dlopen() libappindicator, and we only do it under some circumstances. I suspect the environment that asan runs in is not one of the circumstances where we used to use libappindicator (even if a lot of our users do). My change was to use libappindicator more often (every time it is available), hence the issue is now triggered.

I will try to work out if there is something about the way we are using the library.

timbrown: 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

I can not reproduce the error locally. To me it looks like it's actually caused by an incorrect setup in the clusterfuzz environment (specifically the dbus config is wonky). I have been in contact with ochang@ about fixing this.

timbrown: 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

Just a heads up, M66 Stable cut is on April 12th, 10 days away. This issue is marked as RB-Stable for 66. Please make sure to address this issue prior to stable cut. Thanks! 

I'm working on a workaround which won't use the library in all cases. Specifically, it seems to have issues when there isn't the relevant dbus listener available (although I can't reproduce this locally to confirm). The workaround won't use the library if there isn't the dbus listener.

Removing release blocker label as this is a very unusual set up, and not something that a typical desktop environment would have.

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 bug is not a regression. The change exposed this issue to our testing environment, but it already existed. Also, it requires an extremely unusual desktop environment for the issue to be exposed. It requires (AFAICT) a setup where there is no notification listener or a status icon listener on the dbus. Not that they aren't running, but don't exist on the system at all. I can't really imagine this situation existing on any normal desktop setup.

ClusterFuzz has detected this issue as fixed in range 585262:585267.

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

Fuzzer: meacer_web_ext
Job Type: linux_asan_chrome_mp
Platform Id: linux

Crash Type: UNKNOWN READ
Crash Address: 0x606000350000
Crash State:
  libappindicator3.so.1
  
Sanitizer: address (ASAN)

Recommended Security Severity: Medium

Regressed: https://clusterfuzz.com/revisions?job=linux_asan_chrome_mp&range=539846:539853
Fixed: https://clusterfuzz.com/revisions?job=linux_asan_chrome_mp&range=585262:585267

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

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 6118104225284096 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 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