Issue metadata
Sign in to add a comment
|
Heap-use-after-free in ui::Layer::OnDeviceScaleFactorChanged |
||||||||||||||||||||||
Issue descriptionDetailed report: https://clusterfuzz.com/testcase?key=5744090965344256 Fuzzer: inferno_twister Job Type: linux_asan_chrome_chromeos Platform Id: linux Crash Type: Heap-use-after-free READ 4 Crash Address: 0x6160001597f8 Crash State: ui::Layer::OnDeviceScaleFactorChanged ui::Layer::OnDeviceScaleFactorChanged ui::Layer::OnDeviceScaleFactorChanged Sanitizer: address (ASAN) Recommended Security Severity: High Regressed: https://clusterfuzz.com/revisions?job=linux_asan_chrome_chromeos&range=546997:547001 Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5744090965344256 Additional requirements: Requires Gestures Issue filed automatically. See https://github.com/google/clusterfuzz-tools for more information.
,
Apr 25 2018
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
,
Apr 25 2018
,
Apr 26 2018
,
Apr 30 2018
ClusterFuzz testcase 5744090965344256 appears to be flaky, updating reproducibility label.
,
May 2 2018
sadrul, it looks like you've recently made some changes to https://chromium.googlesource.com/chromium/src/+blame/1621e54dd424f9ac217591fd69fc9bf91d1c30e7/ui/aura/window_tree_host.cc#391 which appears in the crash stack. Could you please take a look or re-assign as appropriate? Thanks.
,
May 2 2018
Looks like CrossFadeObserver [1] is mutating the list of layers (by destroying a tree of layers [2]), but ui::Layers is not set up to handle that [3]. I don't think the change in OnHostResizedInPixels() is related. I think a possible fix is to delay the destruction of CrossFadeObserver (e.g. in the next cycle using PostTask()). Handing off to wutao@ to investigate/triage. [1] https://chromium.googlesource.com/chromium/src/+/1621e54dd424f9ac217591fd69fc9bf91d1c30e7/ash/wm/window_animations.cc#272 [2] https://chromium.googlesource.com/chromium/src/+/1621e54dd424f9ac217591fd69fc9bf91d1c30e7/ash/wm/window_animations.cc#302 [3] https://chromium.googlesource.com/chromium/src/+/1621e54dd424f9ac217591fd69fc9bf91d1c30e7/ui/compositor/layer.cc#962
,
May 2 2018
Hi Sadrul, There are some other cases in CrOS we ::wm::RecreateLayers the layer and delete the old layer owner when finishing some operations. For example [1]. Fix this animation alone seems not the best approach? What is the root cause? IIUC, when Compositor::SetScaleAndSize was called, some of the child layers was deleted? Looks like ui::Layer needs to observe Layer destroy and delete it from the layer tree? I wonder how this was not a problem before? [1] https://cs.chromium.org/chromium/src/chrome/browser/chromeos/arc/voice_interaction/arc_voice_interaction_framework_service.cc?l=123&rcl=27ad30b19f0e5b744703bb1796baa30be1af5027
,
May 12 2018
ClusterFuzz testcase 5744090965344256 is flaky and no longer crashes, so closing issue. If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.
,
Aug 18
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
, Apr 25 2018