Firefox crashes when executing the given javascript

RESOLVED FIXED

Status

()

Product:
Firefox
Component:
Security
Importance:
--
critical
Status:
RESOLVED FIXED
Reported:
8 years ago
Modified:
6 years ago

People

(Reporter: gauravgulati81, Unassigned)

Tracking

({crash, csectype-oom, testcase})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:dos oom])

Attachments

(1 attachment, 1 obsolete attachment)

script used for testing
337 bytes, text/plain
Details
(Reporter)

Description

•
8 years ago 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12

Firefox crashes when executing the given javascript. Please find the test file attached.

Reproducible: Always

Steps to Reproduce:
1. Launch an html page having the following javascript:

<script type="text/javascript">
var num=99999999;
var str = unescape("%u9999%u9999");
        var i = Math.ceil(Math.log(num) / Math.LN2),
            res = str;
        do {
            res += res;
        } while (0 < --i);
		
        document.write(res.slice(0, 999999999999));


</script> 
Actual Results:  
Firefox crashes.

Expected Results:  
Firefox should not crash.
(Reporter)

Comment 1

•
8 years ago 
Created attachment 487196 [details]
Please ignore this script
 (Reporter)

Updated

•
8 years ago
Attachment #487196 - Attachment description: script used for testing → Please ignore this script
 (Reporter)

Comment 2

•
8 years ago 
Created attachment 487197 [details]
script used for testing
 (Reporter)

Comment 3

•
8 years ago 
Please use the following javascript for reproducing the bug:

<html><body>

<script type="text/javascript">
var num=49000000;
var str = unescape("%u9999%u9999");
        var i = Math.ceil(Math.log(num) / Math.LN2),
            res = str;
        do {
            res += res;
        } while (0 < --i);
		
        document.write(res.slice(0, 999999999999));


</script> 
</body></html>

Comment 4

•
8 years ago 
With Firefox 1.9.2 DEBUG on Linux x86-64

*__GI_raise (sig=<value optimized out>) at sysdeps/unix/sysv/linux/raise.c:64
*__GI_abort ()                    at abort.c:92
g_logv ()                         from /lib/libglib-2.0.so.0
g_log ()                          from /lib/libglib-2.0.so.0
g_realloc ()                      from /lib/libglib-2.0.so.0
pango_glyph_string_set_size ()    from /usr/lib/libpango-1.0.so.0
?? ()                   from /usr/lib/pango/1.6.0/modules/pango-basic-fc.so
pango_shape ()                    from /usr/lib/libpango-1.0.so.0
gfxPangoFontGroup::CreateGlyphRunsItemizing gfxPangoFonts.cpp:3088
gfxPangoFontGroup::MakeTextRun    gfx/thebes/src/gfxPangoFonts.cpp:2416
TextRunWordCache::MakeTextRun     gfx/thebes/src/gfxTextRunWordCache.cpp:685
MakeTextRun                       layout/generic/nsTextFrameThebes.cpp:436
BuildTextRunsScanner::BuildTextRunForFrames nsTextFrameThebes.cpp:1783
BuildTextRunsScanner::FlushFrames layout/generic/nsTextFrameThebes.cpp:1214
BuildTextRuns                     layout/generic/nsTextFrameThebes.cpp:1148
nsTextFrame::EnsureTextRun        layout/generic/nsTextFrameThebes.cpp:1972
nsTextFrame::Reflow               layout/generic/nsTextFrameThebes.cpp:6126

g_realloc aborts on OOM - this is the expected behavior.

Comment 5

•
8 years ago 
On Windows, this is likely a dupe of bug 608336.

Comment 6

•
8 years ago 
With Firefox 1.9.2 DEBUG on OSX 10.5 I got the occasional OOM abort from
|operator new|, other than that it just hanged consuming CPU cycles --
no nasty looking crashes (YMMV).
 (Reporter)

Comment 7

•
8 years ago 
Please execute the 2nd attachment to generate the crash.... the 1st attachment was made by mistake.

Updated

•
8 years ago
Attachment #487196 - Attachment is obsolete: true

Comment 8

•
8 years ago 
Yes, my tests above was with attachment 487197 [details].

Comment 9

•
8 years ago 
Testing 1.9.2 debug build on Windows XP with the patch for bug 608336 -
I get only safe OOM abort from |operator new|.
Keywords: testcase
Whiteboard: [sg:dos oom]

Updated

•
8 years ago
Status: UNCONFIRMED → NEW
Depends on: 608336
Ever confirmed: true

Comment 10

•
8 years ago 
Fixed by bug 608336.

Gaurav, please verify with the latest 3.6.13 candidate build:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/3.6.13-candidates/

Note that we will still crash, that is expected, but the crash should be
a deliberate call to abort() or similar when we run out of memory.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
 (Reporter)

Comment 11

•
6 years ago 
Re-tested in version 15.0.1.
The defect is reproducible. The browser crashes as soon as the script is executed.
 (Reporter)

Comment 12

•
6 years ago 
Re-test performed on Win XP SP3.

Comment 13

•
6 years ago 
<in mail to sec@>
Hi,

This bug is reproducible in Firefox version 15.0.1. But, I am unable to re-open the defect in bugzilla.



Thanks,
Gaurav Gulati.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 14

•
6 years ago 
Per comment 10:
Note that we will still crash, that is expected, but the crash should be
a deliberate call to abort() or similar when we run out of memory.

There are other bug reports tracking the work needed to implement
memory quotas per tab and such features to prevent individual pages
from consuming too much memory.

Again, a *safe crash* is expected.  Please don't reopen unless you
see something different - or in that case, better file a new bug.
Status: REOPENED → RESOLVED
Last Resolved: 8 years ago → 6 years ago
Resolution: --- → FIXED
Group: core-security
Keywords: crash, csec-oom
You need to log in before you can comment on or make changes to this bug.