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

John Pettitt
Reported 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.
Attachments
crashlog (43.72 KB, text/plain)
2014-04-29 12:23 PDT, Jeffrey Czerniak 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Jeffrey Czerniak
Comment 1 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?
Jeffrey Czerniak
Comment 2 2014-04-28 17:06:28 PDT
Oh wait, I tried the wrong URL. I am now able to repro.
John Pettitt
Comment 3 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.
Jeffrey Czerniak
Comment 4 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.
John Pettitt
Comment 5 2014-04-28 17:23:51 PDT
Cool thanks. Do I need to re file as non-security or will this bug id suffice?
Jeffrey Czerniak
Comment 6 2014-04-28 17:28:28 PDT
I just removed the security bits, so this bug should suffice.
Alexey Proskuryakov
Comment 7 2014-04-29 12:20:20 PDT
Could someone attach a crash log please?
Jeffrey Czerniak
Comment 8 2014-04-29 12:23:29 PDT
Created attachment 230399 [details] crashlog
Alexey Proskuryakov
Comment 9 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)
Simon Fraser (smfr)
Comment 10 2014-04-29 13:06:54 PDT
iOS crashes should be reported via bugreporter.apple.com
John Pettitt
Comment 11 2014-04-29 13:40:36 PDT
Thanks, Bug opened with apple - ref 16760154
Note You need to log in before you can comment on or make changes to this bug.