Summary: | AX: Safari crashed once in WebCore::AccessibilityObject::ariaIsHidden | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | chris fleizach <cfleizach> | ||||
Component: | Accessibility | Assignee: | chris fleizach <cfleizach> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | aboxhall, apinheiro, commit-queue, ddkilzer, dmazzoni, jcraig, jdiggs, koivisto, mario, samuel_white, simon.fraser, webkit-bug-importer | ||||
Priority: | P2 | Keywords: | InRadar | ||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | All | ||||||
OS: | All | ||||||
Attachments: |
|
Description
chris fleizach
2014-06-12 14:51:22 PDT
The problem looks like if you ask axIsIgnored() on a newly created object, it can actually deallocate itself Created attachment 232992 [details]
patch
Comment on attachment 232992 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=232992&action=review > Source/WebCore/accessibility/AXObjectCache.cpp:433 > + // Sometimes asking accessibilityIsIgnored() will cause the newObject to be deallocated, and then > + // it will disappear when this function is finished, leading to a use-after-free. > + if (newObj->isDetached()) > + return nullptr; Do you really mean deallocated, or just detached? If newObj is truly deallocated, we need to understand why our RefPtr didn't prevent that. Accessing newObj after it has been deallocated is not sound, and isDetached() might return anything if it's called on a deallocated object. (In reply to comment #4) > (From update of attachment 232992 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=232992&action=review > > > Source/WebCore/accessibility/AXObjectCache.cpp:433 > > + // Sometimes asking accessibilityIsIgnored() will cause the newObject to be deallocated, and then > > + // it will disappear when this function is finished, leading to a use-after-free. > > + if (newObj->isDetached()) > > + return nullptr; > > Do you really mean deallocated, or just detached? If newObj is truly deallocated, we need to understand why our RefPtr didn't prevent that. Accessing newObj after it has been deallocated is not sound, and isDetached() might return anything if it's called on a deallocated object. I mean detached. The RefPtr<> in this method is still holding onto the object while we're in the context of the methods stack. as soon as we leave that stack and the RefPtr goes away, the object then becomes deallocated Comment on attachment 232992 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=232992&action=review > Source/WebCore/ChangeLog:8 > + Sometimes asking accessibilityIsIgnored() will cause a newObject to be deallocated. It will Please fix the ChangeLog to use detached. |