Closed Bug 528644 Opened 10 years ago Closed 10 years ago

Crash [@ js_GetUpvar]

Categories

(Core :: JavaScript Engine, defect, critical)

defect
Not set
critical

Tracking

()

VERIFIED FIXED
Tracking Status
blocking2.0 --- -
blocking1.9.2 --- needed
status1.9.2 --- .7-fixed
blocking1.9.1 --- needed
status1.9.1 --- .11-fixed

People

(Reporter: gkw, Assigned: dmandelin)

References

(Blocks 1 open bug)

Details

(5 keywords, Whiteboard: [sg:critical][ccbr][3.6.x]fixed-in-tracemonkey [rc-ridealong])

Crash Data

Attachments

(1 file)

function g(foo) {
  for (a in foo) function() {}
}
(g((eval("\
  function() {\
    for each(b in [0]) {\
      __defineGetter__(\"x\", \
        function(b) \
        eval(\"new function() { yield print(b) }\" ) \
      )\
    } \
    return x\
  }\
"))()))()


crashes js debug and opt shell at js_GetUpvar near null on TM tip on 10.5.8.

autoBisect shows this is probably related to bug 488034:

The first bad revision is:
changeset:   27186:70111870bcf8
user:        Brendan Eich
date:        Mon Apr 13 14:16:15 2009 -0700
summary:     Bug 488034 - Crash [@ js_GetUpvar] or "Assertion failure: (script)->upvarsOffset != 0, at ../jsinterp.cpp" (r=mrbkap).


Debug stack:

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000018
Crashed Thread:  0

Thread 0 Crashed:
0   js-dbg-tm-darwin              	0x00098a46 js_GetUpvar + 76
1   js-dbg-tm-darwin              	0x0008d56c js_Interpret + 111234
2   js-dbg-tm-darwin              	0x0009e9ab __ZL15SendToGeneratorP9JSContext13JSGeneratorOpP8JSObjectP11JSGeneratorl + 561
3   js-dbg-tm-darwin              	0x0009ede8 __ZL12generator_opP9JSContext13JSGeneratorOpPlj + 610
4   js-dbg-tm-darwin              	0x0009ee91 __ZL14generator_nextP9JSContextjPl + 39
5   js-dbg-tm-darwin              	0x0009c1bb js_Invoke + 1503
6   js-dbg-tm-darwin              	0x0009cbb3 js_InternalInvoke + 151
7   js-dbg-tm-darwin              	0x0009fa60 js_CallIteratorNext + 360
8   js-dbg-tm-darwin              	0x000773a2 js_Interpret + 20664
9   js-dbg-tm-darwin              	0x0009b81b js_Execute + 1169
10  js-dbg-tm-darwin              	0x000111ba JS_ExecuteScript + 54
11  js-dbg-tm-darwin              	0x00009e5e __ZL7ProcessP9JSContextP8JSObjectPci + 458
12  js-dbg-tm-darwin              	0x0000aba0 __ZL11ProcessArgsP9JSContextP8JSObjectPPci + 2272
13  js-dbg-tm-darwin              	0x0000af6d main + 953
14  js-dbg-tm-darwin              	0x00001d6b _start + 209
15  js-dbg-tm-darwin              	0x00001c99 start + 41
Flags: blocking1.9.2?
(In reply to comment #0)
> crashes js debug and opt shell at js_GetUpvar near null on TM tip on 10.5.8.

... and occurs without -j.
Whiteboard: [ccbr]
Flags: wanted1.9.2+
Flags: blocking1.9.2?
Flags: blocking1.9.2-
blocking2.0: --- → ?
Group: core-security
Nominating blocking1.9.1? since it got turned security-sensitive and affects 1.9.1 branch.
blocking1.9.1: --- → ?
blocking1.9.1: ? → needed
Flags: wanted1.9.0.x-
Whiteboard: [ccbr] → [ccbr][3.6.x]
Assignee: general → brendan
Status: NEW → ASSIGNED
OS: Mac OS X → All
Hardware: x86 → All
Is this a nearly-null memory read, not exploitable?

/be
Assignee: brendan → dmandelin
I have the cause of the crash. The crash is in trying to access |b| in |yield print(b)|. This is compiled as a JSOP_GETUPVAR in a function at static level 5 getting a variable |x| defined at static level 3 (|function (b) ...|). But the function at level 3 has returned by the time we re-enter the function that accesses |b|, so we crash.

It seems that the generator function should not be compiled with JSOP_GETUPVAR at all, since it escapes. I'll have to dig in to the regressing patch and the closure compiler to figure out the exact cause and solution.
Attached patch PatchSplinter Review
Attachment #420408 - Flags: review?(mrbkap)
Attachment #420408 - Flags: review?(mrbkap) → review+
http://hg.mozilla.org/tracemonkey/rev/a578f79c7dd2
Whiteboard: [ccbr][3.6.x] → [ccbr][3.6.x]fixed-in-tracemonkey
http://hg.mozilla.org/mozilla-central/rev/a578f79c7dd2
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: [ccbr][3.6.x]fixed-in-tracemonkey → [ccbr][3.6.x]fixed-in-tracemonkey [rc-ridealong]
blocking2.0: ? → -
This "ridealong" got left behind.
blocking1.9.2: --- → needed
Whiteboard: [ccbr][3.6.x]fixed-in-tracemonkey [rc-ridealong] → [sg:critical][ccbr][3.6.x]fixed-in-tracemonkey [rc-ridealong]
Attachment #420408 - Flags: approval1.9.2.6?
Comment on attachment 420408 [details] [diff] [review]
Patch

a=LegNeato for 1.9.2.6
Attachment #420408 - Flags: approval1.9.2.6? → approval1.9.2.6+
Comment on attachment 420408 [details] [diff] [review]
Patch

Also approving for 1.9.1.11
Attachment #420408 - Flags: approval1.9.1.11+
gary: is there is a way to verify this fix in a debug build ?
Any update on this? Gary?
(In reply to comment #14)
> Any update on this? Gary?

I no longer crash using TM changeset 7cb520995757 on a 32-bit debug shell. Verified fixed.

Also verified on 1.9.2 changeset df760e6d4ddc and 1.9.1 changeset 2eb0724d74f8
Group: core-security
Flags: in-testsuite+
Crash Signature: [@ js_GetUpvar]
Verified per comment 15.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.