Bug 132312

Summary: Reproducible crash in LayoutState constructor on a WordPress page with jetpack comments
Product: WebKit Reporter: John Pettitt <j>
Component: Layout and RenderingAssignee: Nobody <webkit-unassigned>
Status: RESOLVED INVALID    
Severity: Major CC: ap, bdakin, dbates, ddkilzer, jeffcz, jonlee, simon.fraser
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: iPhone / iPad   
OS: iOS 7.0   
URL: http://ptt.staging.wpengine.com/2014/04/things-i-learned-at-burning-man-treat-your-staff-as-if-they-are-volunteers/
Attachments:
Description Flags
crashlog none

Description John Pettitt 2014-04-28 16:53:14 PDT 
Bug triggered after enabling Wordpress jetpack comment on a specific Wordpress theme.  Accessing the page from an iPhone or iPad (and I'm told but haven't verified from android) causes an immediate hard browser crash dumping back to the device home screen.

Accessing the same page from the desktop or from emulation in chrome canary doesn't crash.   Remote debugging on safari exits at the point of the crash giving no useful data.

The production version of the same page (jetpack comments disabled) works fine http://p.tt/2014/04/things-i-learned-at-burning-man-treat-your-staff-as-if-they-are-volunteers/

Sorry I can't be more specific but on the basis that any crash is a potential security hole I'm logging this as a security bug until proven otherwise.
Comment 1 Jeffrey Czerniak 2014-04-28 17:04:45 PDT 
I don't see any crash on an iPhone 5 running iOS 7.1.1.  Can you please provide more details about your configuration?
Comment 2 Jeffrey Czerniak 2014-04-28 17:06:28 PDT 
Oh wait, I tried the wrong URL.  I am now able to repro.
Comment 3 John Pettitt 2014-04-28 17:10:24 PDT 
The diff between the 2 urls is the one that crashes has jetpack comments enabled and the other doesn't.
Comment 4 Jeffrey Czerniak 2014-04-28 17:19:22 PDT 
Multiple repro instances on iOS show that this always triggers the same non-exploitable null-deref crash.

In addition, we tested with an instrumented WebKit build on OS X and saw no evidence of memory corruption or pointer shenanigans.  This doesn't look like a security bug.
Comment 5 John Pettitt 2014-04-28 17:23:51 PDT 
Cool thanks.  Do I need to re file as non-security or will this bug id suffice?
Comment 6 Jeffrey Czerniak 2014-04-28 17:28:28 PDT 
I just removed the security bits, so this bug should suffice.
Comment 7 Alexey Proskuryakov 2014-04-29 12:20:20 PDT 
Could someone attach a crash log please?
Comment 8 Jeffrey Czerniak 2014-04-29 12:23:29 PDT 
Created attachment 230399 [details]
crashlog
Comment 9 Alexey Proskuryakov 2014-04-29 12:58:21 PDT 
Thread 2 name:  WebThread
Thread 2 Crashed:
0   WebCore                       	0x35964f82 WebCore::LayoutState::LayoutState(WebCore::LayoutState*, WebCore::RenderBox*, WebCore::LayoutSize const&, WebCore::LayoutUnit, bool, WebCore::ColumnInfo*) + 282 (LayoutSize.h:50)
1   WebCore                       	0x35964e5a WebCore::LayoutState::LayoutState(WebCore::LayoutState*, WebCore::RenderBox*, WebCore::LayoutSize const&, WebCore::LayoutUnit, bool, WebCore::ColumnInfo*) + 26 (LayoutState.cpp:138)
2   WebCore                       	0x35964e04 WebCore::RenderView::pushLayoutState(WebCore::RenderBox*, WebCore::LayoutSize const&, WebCore::LayoutUnit, bool, WebCore::ColumnInfo*) + 164 (RenderView.h:262)
3   WebCore                       	0x35961206 WebCore::RenderBlock::layoutBlock(bool, WebCore::LayoutUnit) + 438 (RenderView.h:406)
4   WebCore                       	0x35968a4c WebCore::RenderLayer::updateScrollbarsAfterLayout() + 720 (RenderLayer.cpp:3331)
5   WebCore                       	0x35968276 WebCore::RenderLayer::updateScrollInfoAfterLayout() + 210 (RenderLayer.cpp:3384)
Comment 10 Simon Fraser (smfr) 2014-04-29 13:06:54 PDT 
iOS crashes should be reported via bugreporter.apple.com
Comment 11 John Pettitt 2014-04-29 13:40:36 PDT 
Thanks, Bug opened with apple - ref 16760154