Closed Bug 515771 Opened 12 years ago Closed 8 years ago

Data from Faulting Address controls Branch Selection star ting at gklayout!nsTextFrameUtils::TransformText+0x00000000000000cc

Categories

(Core :: MathML, defect)

1.9.1 Branch
x86
All
defect
Not set
critical

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?
blocking1.9.1: --- → ?
Group: core-security
blocking1.9.1: ? → ---
Flags: blocking1.9.2?
Whiteboard: [sg:dos] null deref (testcase 2 from bug 476547)
Whiteboard: [sg:dos] null deref (testcase 2 from bug 476547) → [sg:dos] null deref (testcase 2 from bug 476547) [ccbr]
Is this still happening in current trunk build?
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: 8 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.