RESOLVED FIXED 64693
-webkit-marquee with anonymous node causes segmentation fault in Node::document 
https://bugs.webkit.org/show_bug.cgi?id=64693
Summary -webkit-marquee with anonymous node causes segmentation fault in Node::document
noel gordon
Reported 2011-07-18 07:26:22 PDT
Reproduction: <!DOCTYPE html> <style> p:first-letter { overflow: -webkit-marquee; float: left; } </style> <p>a</p> Crash reproduces so far in: Safari 5.0.5 (7533.21.1) Win32 Chrome 14.0.822.0 (Developer Build 92402) WebKit 535.1 (trunk@90358) Linux Ubuntu 11.04 (x86_64), Win32 Chrome 13.0.782.56 (Official Build 92025) Beta Linux Ubuntu 11.04 (x86_64) Chrome 12.0.742.122 Stable Win32 crbug.com/89595
Attachments
Patch (3.25 KB, patch)
2011-07-28 12:05 PDT, Emil A Eklund 		no flags
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Abhishek Arya
Comment 1 2011-07-18 08:57:14 PDT
Noel, why did you mark this security ? To me, this looks a obvious null ptr exception crash. this and renderer() vtables are all right and renderer()->node() is an anonymous node, so null. I have also hit this in my fuzzers, so remember analyzing this. Am i missing anything ? renderer()->node()->document()->eventQueue()->enqueueOrDispatchScrollEvent(renderer()->node(), EventQueue::ScrollEventElementTarget);
Lucas Forschler
Comment 2 2011-07-18 09:41:10 PDT
<rdar://problem/9792726>
noel gordon
Comment 3 2011-07-20 00:36:43 PDT
(In reply to comment #1) > Noel, why did you mark this security ? I was not concerned about Chromium; there it's a tab crash. My concern was for Safari and other WebCore users. Should I consider simple ways to crash those users as a security matter or not?
Abhishek Arya
Comment 4 2011-07-21 11:22:16 PDT
Null ptr crashes are not security bugs.
Alexey Proskuryakov
Comment 5 2011-07-22 10:49:26 PDT
ASSERTION FAILED: this /Users/ap/Safari/OpenSource/Source/WebCore/dom/Node.h(365) : WebCore::Document* WebCore::Node::document() const 1 WebCore::Node::document() const 2 WebCore::RenderLayer::scrollTo(int, int) 3 WebCore::RenderLayer::setScrollOffset(WebCore::IntPoint const&) 4 WebCore::ScrollableArea::setScrollOffsetFromAnimation(WebCore::IntPoint const&) 5 WebCore::ScrollAnimator::notityPositionChanged() 6 WebCore::ScrollAnimatorMac::notityPositionChanged() 7 WebCore::ScrollAnimatorMac::immediateScrollToPoint(WebCore::FloatPoint const&) 8 WebCore::ScrollAnimatorMac::scrollToOffsetWithoutAnimation(WebCore::FloatPoint const&) 9 WebCore::ScrollableArea::scrollToOffsetWithoutAnimation(WebCore::FloatPoint const&) 10 WebCore::RenderLayer::scrollToOffset(int, int, WebCore::RenderLayer::ScrollOffsetClamping) 11 WebCore::RenderMarquee::start() ...
Emil A Eklund
Comment 6 2011-07-28 12:05:17 PDT
Created attachment 102281 [details] Patch
Hajime Morrita
Comment 7 2011-07-29 01:08:33 PDT
Comment on attachment 102281 [details] Patch How about to use renderer()->document() ?
Emil A Eklund
Comment 8 2011-07-29 11:24:39 PDT
(In reply to comment #7) > (From update of attachment 102281 [details]) > How about to use renderer()->document() ? That would allow us to dispatch a scroll event but as there is no corresponding dom node to set the target to I'm not sure how useful that event would be.
WebKit Review Bot
Comment 9 2011-07-29 15:49:03 PDT
Comment on attachment 102281 [details] Patch Clearing flags on attachment: 102281 Committed r92025: <http://trac.webkit.org/changeset/92025>
WebKit Review Bot
Comment 10 2011-07-29 15:49:09 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.