Open Bug 616361 Opened 14 years ago Updated 2 years ago

OOM exception from excessive XML entity expansion

Categories

(Core :: Layout, defect)

x86
Windows 7
defect

Tracking

()

People

(Reporter: bsterne, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: crash, stackwanted, testcase, Whiteboard: [sg:dos oom])

Attachments

(1 file)

Attached file testcase (zipped)
Frank Boldewin reported the following to security@m.o. His stack showed he crashed in kernel32.dll, but when I loaded the testcase (attached) I got a crash in xul.dll, though unfortunately the crash report didn't have symbols. I haven't had a chance to look any further into the issue at this point. From his email: ------ hey, i was playing with several XML parsers how they react, when it comes to XML bombs. firefox 3.6.11 under windows just seems to crash after some time with a abnormal termination error. my exception logger show me that the exception (code: e06d7363, this is a Microsoft C++ Exception) comes from kernel32.dll---->raiseexception find attached a sample xml-bomb for testing ---> in the firefox url bar just type: c:\xml-bomb.xml donno if this is what you've expected. maybe there is a better way to handle this in firefox. cheers, frank --- Exception detected --- PID: 2528 First Chance: YES Exception code: e06d7363 (UNKNOWN) Exception addr: 7c812afb Image (from OpenProcess): C:\Programme\Mozilla Firefox\firefox.exe Image (from EPROCESS) : firefox.exe Param count : 3 Params: 19930520 0013a52c 781caa24 Eax: 0013a494 Edx: 781d7ba8 Ecx: 00000000 Ebx: 09e59b00 Esi: 0013a51c Edi: 1cb00008 Esp: 0013a490 Ebp: 0013a4e4 Eip: 7c812afb EFlags: 00000206 CF: 0 PF: 1 AF: 0 ZF: 0 SF: 0 TF: 0 IF: 1 DF: 0 OF: 0 NT: 0 RF: 0 VM: 0 AC: 0 ID: 0 IOPL: 0 VIF: 0 VIP: 0 Stack: 05ffa54a e06d7363 00000001 00000000 7c812afb 00000003 19930520 0013a52c 781caa24 0000000c 78132e76 0081b08c 781a8a50 7813d051 0081b08c 781a8a50 Code: [7c812afb] 5e POP ESI [7c812afc] c9 LEAVE [7c812afd] c2 1000 RET 0x10 [7c812b00] 85ff TEST EDI, EDI [7c812b02] 0f8e 3693ffff JLE 0x7c80be3e [7c812b08] 8b55 fc MOV EDX, [EBP-0x4] [7c812b0b] 8955 0c MOV [EBP+0xc], EDX [7c812b0e] 0fb716 MOVZX EDX, [ESI] [7c812b11] 8b7d f8 MOV EDI, [EBP-0x8] [7c812b14] 8a143a MOV DL, [EDX+EDI] [7c812b17] 8811 MOV [ECX], DL [7c812b19] 8b78 0c MOV EDI, [EAX+0xc] [7c812b1c] 0fb6d2 MOVZX EDX, DL [7c812b1f] 66 8b1457 MOV DX, [EDI+EDX*2] [7c812b23] 66 3b16 CMP DX, [ESI] [7c812b26] 0f85 0b8c0300 JNZ 0x7c84b737
I loaded the file in Linux 64 debug build. The process took 1.3 GB of RAM and didn't crash. It stopped responding to user events for a prolonged time (maybe a couple of minutes). That time was spent in font code apparently laying out the huge text node. The huge text node wasn't painted in the resulting XSLT-generated tree view and an attempt to collapse the 'kaboom' node made the process get entangled in gfxFontGroup for a prolonged time again.
We need at least a stack trace from windows here to know what rating to put on this bug.
Keywords: testcase
ugh--please save dumps in a file and add them as attachments. Making the bug unreadable doesn't help.
Whiteboard: [sg:dos oom]
Group: core-security
Summary: Investigate crash from "XML bomb" → OOM exception from excessive XML entity expansion
Note: I tagged comment 7 as "typo" to autocollapse it, so that this bug remains readable. (Readers can expand it with "+", if they want to see the crash backtrace.) It basically just shows us OOM'ing in TextRunWordCache::MakeTextRun, which confirms what bz said in comment 1. See also similar bug 1192544, which has us OOM'ing in parser code, from a similar testcase that uses a nested mega-<!ENTITY> in a SVG or XML attribute.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: