toSource() exposes random memory or crashes [@ memcpy] [@ js_obj_toSource]

VERIFIED DUPLICATE of bug 311497

Status

()

Core
JavaScript Engine
P1
critical
VERIFIED DUPLICATE of bug 311497
12 years ago
7 years ago

People

(Reporter: Jesse Ruderman, Assigned: brendan)

Tracking

(Blocks: 1 bug, {crash, js1.6, regression})

Trunk
mozilla1.8beta5
crash, js1.6, regression
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:dupe 311497] testcase from bug 306939, crash signature)

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
I found this bug while trying to reduce the testcase for bug 307809.  Since I
haven't completely reduced the testcase, this bug should remain
security-sensitive until bug 307809 and bug 306939 are public, or the
non-reduced testcase on this bug should be scrubbed before this bug is made public.
(Reporter)

Comment 1

12 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051004
Firefox/1.6a1 (DEBUG)

Steps to reproduce:

1. Load the testcase

Result: Firefox might crash in js_obj_toSource. It crashes at the line
"js_strncpy(&chars[nchars], vchars, vlength);" with vchars an invalid pointer,
and chars containing "{origCount:632, fun:" followed by random gibberish.

2. Look at the line that starts with "{origCount:632"

Result: This line usually contains random gibberish where it should contain a
function in parens.
(Reporter)

Comment 2

12 years ago
Created attachment 198543 [details]
testcase (not reduced)
(Reporter)

Comment 3

12 years ago
Forgot to mention in comment 0: since this bug seems to make Firefox read random
memory and expose it to web content, it is probably a security hole.
(Reporter)

Comment 4

12 years ago
Created attachment 198545 [details]
stack trace
(Assignee)

Comment 5

12 years ago
Can you make a reduced js shell (or xpcshell) testcase?

Any idea of how old this bug is, its regression window bounds?

/be
(Assignee)

Comment 6

12 years ago
I've loaded the testcase a bunch of times and I can't see any corruption.  This
is with my trunk build linked 9-Sep-2005.

/be
It sounds like Purify may be able to help with this. I'll see if I can get my
hands on a copy tomorrow.
(Reporter)

Comment 8

12 years ago
Regression range: between 2005-04-29 and 2005-05-07.
Keywords: crash, regression
Whiteboard: [sg:fix]?
In a 2005-05-04-06 build, I see this about 80% of the time on that testcase.

In a 2005-05-03-06 build I have yet to see a problem.

Bonsai range:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-05-03+04%3A00%3A00&maxdate=2005-05-04+08%3A00%3A00&cvsroot=%2Fcvsroot
On a windows 1.5b2 Firefox build I've yet to see a corruption problem.

On a windows trunk Seamonkey build running under Purify I see the corruption
most of the time (always on item 631), and Purify reports a Free Memory Read
each time I do. The script takes a long time to run under purify and the FMR is
reported immediately after I click "continue" on the unresponsive script dialog.

When running the same trunk seamonkey build not under Purify I have yet to see
any corruption.

[E] FMR: Free memory read in memcpy {6 occurrences}
        Reading 106 bytes from 0x10a8d1e0 (106 bytes at 0x10a8d1e0 illegal)
        Address 0x10a8d1e0 is at the beginning of a 108 byte block
        Address 0x10a8d1e0 points to a malloc'd block in heap 0x01d90000
        Thread ID: 0xea4
        Error location
            memcpy         [C:\dev\seamonkey\mozilla\obj-opt\dist\bin\js3250.dll]
            js_obj_toSource [c:\dev\seamonkey\mozilla\js\src\jsobj.c:940]
            js_Invoke      [c:\dev\seamonkey\mozilla\js\src\jsinterp.c:1163]
        Allocation location
            malloc        
[F:\VS70Builds\3052\vc\crtbld\crt\src\intel\memset.asm:53]
            JS_malloc      [c:\dev\seamonkey\mozilla\js\src\jsapi.c:1593]
            js_InflateString [c:\dev\seamonkey\mozilla\js\src\jsstr.c:2870]
            JS_NewStringCopyZ [c:\dev\seamonkey\mozilla\js\src\jsapi.c:4124]
            js_GetPrinterOutput [c:\dev\seamonkey\mozilla\js\src\jsopcode.c:514]
            JS_DecompileFunction [c:\dev\seamonkey\mozilla\js\src\jsapi.c:3811]
            js_fun_toString [c:\dev\seamonkey\mozilla\js\src\jsfun.c:1431]
            fun_toSource   [c:\dev\seamonkey\mozilla\js\src\jsfun.c:1448]
            js_Invoke      [c:\dev\seamonkey\mozilla\js\src\jsinterp.c:1163]
        Free location
            free           [f:\vs70builds\3052\vc\crtbld\crt\src\ioinit.c:42]
            js_FinalizeStringRT [c:\dev\seamonkey\mozilla\js\src\jsstr.c:2690]
            js_FinalizeString [c:\dev\seamonkey\mozilla\js\src\jsstr.c:2671]
            js_GC          [c:\dev\seamonkey\mozilla\js\src\jsgc.c:1839]
            js_ForceGC     [c:\dev\seamonkey\mozilla\js\src\jsgc.c:1510]
            JS_GC          [c:\dev\seamonkey\mozilla\js\src\jsapi.c:1849]
            nsJSContext::Notify(nsITimer *)
[c:\dev\seamonkey\mozilla\dom\src\base\nsjsenvironment.cpp:2156]
            nsTimerImpl::Fire(void)
[c:\dev\seamonkey\mozilla\xpcom\threads\nstimerimpl.cpp:397]
            nsTimerManager::FireNextIdleTimer(void)
[c:\dev\seamonkey\mozilla\xpcom\threads\nstimerimpl.cpp:626]
            nsAppShell::GetNativeEvent(int&,void *&)
[c:\dev\seamonkey\mozilla\widget\src\windows\nsappshell.cpp:196]
Status: NEW → ASSIGNED
So in js_obj_toSource we do:

 848                           valstr = js_ValueToSource(cx, val[j]);
...
 854 brendan 3.106             vchars = JSSTRING_CHARS(valstr);
...
 873 brendan 3.20              if (!JSVAL_IS_PRIMITIVE(val[j]) && vchars[0] !=
'#') {
 874                               he = js_EnterSharpObject(cx,
JSVAL_TO_OBJECT(val[j]), NULL,
 875                                                        &vsharp);
 
Can't that GC valstr?  We access vchars after this point...
(Assignee)

Comment 12

12 years ago
Presumably, WAY_TOO_MUCH_GC would smoke this out right away.  Now why doesn't
that argv[1+j] local root protect valstr?  Have to dig into this tonight.

/be
Assignee: general → brendan
Status: ASSIGNED → NEW
Flags: blocking1.8rc1+
Keywords: js1.6
OS: Windows XP → All
Priority: -- → P1
Hardware: PC → All
Target Milestone: --- → mozilla1.8beta5
Note that none of my current builds (including the TOO_MUCH_GC one) showed the
problem... :(
(Assignee)

Comment 14

12 years ago
dveditz: can you get full stacks from purify?

/be
Status: NEW → ASSIGNED
I ran this under purify as well and I saw another problem before the one in
toSource(). What I saw was:

[E] IPW: Invalid pointer write in nsImageWin::CreateImageWithAlphaBits(HDC__ *)
{1 occurrence}
        Writing 1 byte to 0x09520fff (1 byte at 0x09520fff illegal)
        Address 0x09520fff points into a committed VirtualAlloc'd block 
        Thread ID: 0xe54
        Error location
            nsImageWin::CreateImageWithAlphaBits(HDC__ *)
[e:\tip\mozilla\gfx\src\windows\nsimagewin.cpp:453]
                      }
                    }
                  }
             =>   mIsOptimized = PR_TRUE;
                }
                
                /** ---------------------------------------------------
            nsImageWin::CreateDDB(void)
[e:\tip\mozilla\gfx\src\windows\nsimagewin.cpp:1500]
            nsImageWin::Draw(nsIRenderingContext&,nsIDrawingSurface
*,int,int,int,int,int,int,int,int)
[e:\tip\mozilla\gfx\src\windows\nsimagewin.cpp:512]
            nsRenderingContextImpl::DrawImage(imgIContainer *,nsRect
const&,nsRect const&) [e:\tip\mozilla\gfx\src\shared\nsrenderingcontextimpl.cpp:378]
            nsImageBoxFrame::PaintImage(nsIRenderingContext&,nsRect
const&,nsFramePaintLayer)
[e:\tip\mozilla\layout\xul\base\src\nsimageboxframe.cpp:461]
            nsImageBoxFrame::Paint(nsPresContext *,nsIRenderingContext&,nsRect
const&,nsFramePaintLayer,UINT)
[e:\tip\mozilla\layout\xul\base\src\nsimageboxframe.cpp:403]
            nsBoxFrame::PaintChild(nsPresContext *,nsIRenderingContext&,nsRect
const&,nsIFrame *,nsFramePaintLayer,UINT)
[e:\tip\mozilla\layout\xul\base\src\nsboxframe.cpp:1478]
            nsBoxFrame::PaintChildren(nsPresContext
*,nsIRenderingContext&,nsRect const&,nsFramePaintLayer,UINT)
[e:\tip\mozilla\layout\xul\base\src\nsboxframe.cpp:1603]
            nsBoxFrame::Paint(nsPresContext *,nsIRenderingContext&,nsRect
const&,nsFramePaintLayer,UINT)
[e:\tip\mozilla\layout\xul\base\src\nsboxframe.cpp:1433]
            nsBoxFrame::PaintChild(nsPresContext *,nsIRenderingContext&,nsRect
const&,nsIFrame *,nsFramePaintLayer,UINT)
[e:\tip\mozilla\layout\xul\base\src\nsboxframe.cpp:1478]

Whether that's related to this or not I don't know, but it seems to me that it's
possible that the above problem could trigger other problems in code that runs
after this didi. The place of the crash seems a bit too consistent for me to bet
too much on these two issues being related, but who knows...
(Assignee)

Comment 16

12 years ago
Without full stacks I can't be sure, but say the Allocation and Error stacks
have a common prefix.  When the heck could the Free stack, a GC from a timer,
have possibly run?  Could it be somehow nesting under the slow script dialog!?

/be
(Assignee)

Comment 17

12 years ago
Per igor, strongly suspect dup of bug 311497.

/be
Depends on: 311497
(Assignee)

Updated

12 years ago
No longer depends on: 311497
(Assignee)

Comment 18

12 years ago
I can't reproduce with the non-reduced testcase, with the fix to bug 311497 in
my build (and in the trunk).  Dup'ing forward, someone who could reliably
reproduce this please verify.

/be

*** This bug has been marked as a duplicate of 311497 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → DUPLICATE

Updated

12 years ago
Flags: blocking1.8rc1+
(Reporter)

Comment 19

12 years ago
I can't reproduce this bug any more.  Verifying as a dup.
Status: RESOLVED → VERIFIED
(Reporter)

Updated

12 years ago
Whiteboard: [sg:fix]?
Blocks: 306939
Whiteboard: [sg:dupe 311497] randomstyles testcase (bug 306939)
Group: security
Whiteboard: [sg:dupe 311497] randomstyles testcase (bug 306939) → [sg:dupe 311497] testcase from bug 306939

Comment 20

11 years ago
/cvsroot/mozilla/js/tests/js1_5/extensions/regress-311161.js,v  <--  regress-311161.js
initial revision: 1.1
done
Flags: in-testsuite+
Crash Signature: [@ memcpy] [@ js_obj_toSource]
You need to log in before you can comment on or make changes to this bug.