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

Status: VERIFIED DUPLICATE of bug 311497

(Core :: JavaScript Engine, defect, P1)

Description

[Jesse Ruderman]

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.

Comment 1

[Jesse Ruderman]

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.

Comment 2

[Jesse Ruderman]

Attachment: testcase (not reduced)

Comment 3

[Jesse Ruderman]

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.

Comment 4

[Jesse Ruderman]

Attachment: stack trace

Comment 5

[Brendan Eich [:brendan]]

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

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

/be

Comment 6

[Brendan Eich [:brendan]]

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

Comment 7

[Blake Kaplan (:mrbkap) (inactive)]

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

Comment 8

[Jesse Ruderman]

Regression range: between 2005-04-29 and 2005-05-07.

Comment 9

[Boris Zbarsky [:bzbarsky]]

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

Comment 10

[Daniel Veditz [:dveditz]]

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]

Comment 11

[Boris Zbarsky [:bzbarsky]]

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...

Comment 12

[Brendan Eich [:brendan]]

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

Comment 13

[Boris Zbarsky [:bzbarsky]]

Note that none of my current builds (including the TOO_MUCH_GC one) showed the
problem... :(

Comment 14

[Brendan Eich [:brendan]]

dveditz: can you get full stacks from purify?

/be

Comment 15

[Johnny Stenback (:jst)]

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...

Comment 16

[Brendan Eich [:brendan]]

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

Comment 17

[Brendan Eich [:brendan]]

Per igor, strongly suspect dup of bug 311497.

/be

Comment 18

[Brendan Eich [:brendan]]

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 ***

Comment 19

[Jesse Ruderman]

I can't reproduce this bug any more.  Verifying as a dup.

Comment 20

[Bob Clary [:bc] (inactive)]

/cvsroot/mozilla/js/tests/js1_5/extensions/regress-311161.js,v  <--  regress-311161.js
initial revision: 1.1
done