Closed
Bug 515771
Opened 14 years ago
Closed 9 years ago
Data from Faulting Address controls Branch Selection star ting at gklayout!nsTextFrameUtils::TransformText+0x00000000000000cc
Categories
(Core :: MathML, defect)
Tracking
()
RESOLVED
INCOMPLETE
Tracking | Status | |
---|---|---|
status1.9.1 | --- | wanted |
People
(Reporter: cbook, Unassigned)
References
()
Details
(Keywords: crash, testcase, Whiteboard: [sg:dos] null deref (testcase 2 from bug 476547) [ccbr])
steps to reproduce: Load: https://bugzilla.mozilla.org/attachment.cgi?id=360187 testcase from bug 476547 also crashes opt builds -> http://crash-stats.mozilla.com/report/index/7968b75d-6cae-45d2-8c8e-dc1ef2090910?p=1 (c40.af4): Access violation - code c0000005 (!!! second chance !!!) eax=00000000 ebx=7ffde000 ecx=00cfdf70 edx=00000000 esi=00000000 edi=0012d560 eip=019dbc8c esp=0012a7b4 ebp=0012a7d8 iopl=0 nv up ei ng nz ac pe cy cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000297 gklayout!nsTextFrameUtils::TransformText+0xcc: 019dbc8c 8a08 mov cl,byte ptr [eax] ds:0023:00000000=?? 0:000> cdb: Reading initial command '!load winext\msec.dll;.logappend;!exploitab le;k;q' Exploitability Classification: UNKNOWN Recommended Bug Title: Data from Faulting Address controls Branch Selection star ting at gklayout!nsTextFrameUtils::TransformText+0x00000000000000cc (Hash=0x662f 445c.0x560c777c) The data from the faulting address is later used to determine whether or not a b ranch is taken. ChildEBP RetAddr 0012a7d8 01974b14 gklayout!nsTextFrameUtils::TransformText+0xcc 0012bc30 01973d0a gklayout!BuildTextRunsScanner::BuildTextRunForFrames+0x5b4 0012cc64 01974317 gklayout!BuildTextRunsScanner::FlushFrames+0x14a 0012ccbc 01974473 gklayout!BuildTextRunsScanner::ScanFrame+0x127 0012cd10 01976958 gklayout!BuildTextRunsScanner::ScanFrame+0x283 0012d088 019760d2 gklayout!BuildTextRuns+0x5b8 0012d0f8 0197f606 gklayout!nsTextFrame::EnsureTextRun+0xb2 0012d1f4 0197f998 gklayout!nsTextFrame::AddInlinePrefWidthForFlow+0x46 0012d214 019905a7 gklayout!nsTextFrame::AddInlinePrefWidth+0xb8 0012d270 019a88a9 gklayout!nsContainerFrame::DoInlineIntrinsicWidth+0x177 0012d288 01998857 gklayout!nsInlineFrame::AddInlinePrefWidth+0x19 0012d310 019307ee gklayout!nsBlockFrame::GetPrefWidth+0x2e7 0012d3a8 01df9ee5 gklayout!nsLayoutUtils::IntrinsicForContainer+0x15e 0012d448 01df9e42 gklayout!nsMathMLContainerFrame::GetIntrinsicWidth+0x35 0012d470 019687ad gklayout!nsMathMLContainerFrame::GetMinWidth+0x32 0012d48c 019906ed gklayout!nsFrame::ShrinkWidthToFit+0x1d 0012d4ac 019682a1 gklayout!nsContainerFrame::ComputeAutoSize+0x6d 0012d53c 01995f68 gklayout!nsFrame::ComputeSize+0x61 0012d5b8 01993397 gklayout!nsHTMLReflowState::InitConstraints+0x5d8 0012d5d8 01993038 gklayout!nsHTMLReflowState::Init+0xe7 quit:
Flags: blocking1.9.2?
Reporter | ||
Updated•14 years ago
|
blocking1.9.1: --- → ?
Updated•14 years ago
|
Group: core-security
blocking1.9.1: ? → ---
status1.9.1:
--- → wanted
Flags: blocking1.9.2?
Whiteboard: [sg:dos] null deref (testcase 2 from bug 476547)
Updated•14 years ago
|
Whiteboard: [sg:dos] null deref (testcase 2 from bug 476547) → [sg:dos] null deref (testcase 2 from bug 476547) [ccbr]
Comment 1•12 years ago
|
||
Is this still happening in current trunk build?
Comment 2•9 years ago
|
||
I can't reproduce it with a trunk build. I think this has been fixed by bug 476547.
Whiteboard: [sg:dos] null deref (testcase 2 from bug 476547) [ccbr] → [sg:dos] null deref (testcase 2 from bug 476547) [ccbr][closeme 2014-03-06]
Resolved per whiteboard
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → INCOMPLETE
Whiteboard: [sg:dos] null deref (testcase 2 from bug 476547) [ccbr][closeme 2014-03-06] → [sg:dos] null deref (testcase 2 from bug 476547) [ccbr]
You need to log in
before you can comment on or make changes to this bug.
Description
•