Bug 64693 - -webkit-marquee with anonymous node causes segmentation fault in Node::document
Summary: -webkit-marquee with anonymous node causes segmentation fault in Node::document
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Emil A Eklund
Keywords: InRadar
Depends on:
Reported: 2011-07-18 07:26 PDT by noel gordon
Modified: 2011-07-29 15:49 PDT (History)
9 users (show)

See Also:

Patch (3.25 KB, patch)
2011-07-28 12:05 PDT, Emil A Eklund
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description noel gordon 2011-07-18 07:26:22 PDT

 <!DOCTYPE html>
  <style> p:first-letter { overflow: -webkit-marquee; float: left; } </style>

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

Comment 1 Abhishek Arya 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);
Comment 2 Lucas Forschler 2011-07-18 09:41:10 PDT
Comment 3 noel gordon 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?
Comment 4 Abhishek Arya 2011-07-21 11:22:16 PDT
Null ptr crashes are not security bugs.
Comment 5 Alexey Proskuryakov 2011-07-22 10:49:26 PDT
/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()
Comment 6 Emil A Eklund 2011-07-28 12:05:17 PDT
Created attachment 102281 [details]
Comment 7 Hajime Morrita 2011-07-29 01:08:33 PDT
Comment on attachment 102281 [details]

How about to use renderer()->document() ?
Comment 8 Emil A Eklund 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.
Comment 9 WebKit Review Bot 2011-07-29 15:49:03 PDT
Comment on attachment 102281 [details]

Clearing flags on attachment: 102281

Committed r92025: <http://trac.webkit.org/changeset/92025>
Comment 10 WebKit Review Bot 2011-07-29 15:49:09 PDT
All reviewed patches have been landed.  Closing bug.