368534 - ordering problem in script_toSource

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Brian Crowder]

Attachment: check instanceof first

I realized after checking it in that my recent patch introduced an ordering problem that was recommended in a review for a later patch.  Here's the fix.  I landed my broken-ness on both branches, of course.  Yay me.

This may not _itself_ be security-critical but it is a real bug, and is related to patches from security-critical bugs, so I have marked it security sensitive for now.  Bug 367120 is where I originally perpetrated my mayhem.

Comment 1

[Brian Crowder]

Attachment: with context

Sorry for bugspam.

Comment 2

[Daniel Veditz [:dveditz]]

Comment on attachment 253143 [details] [diff] [review]
with context

a=dveditz for 1.8/1.8.0 branches

Comment 3

[Brian Crowder]

Trunk:
Checking in jsscript.c;
/cvsroot/mozilla/js/src/jsscript.c,v  <--  jsscript.c
new revision: 3.134; previous revision: 3.133
done

Moz-1.8:
Checking in jsscript.c;
/cvsroot/mozilla/js/src/jsscript.c,v  <--  jsscript.c
new revision: 3.79.2.22; previous revision: 3.79.2.21
done

Moz-1.8.0:
Checking in jsscript.c;
/cvsroot/mozilla/js/src/jsscript.c,v  <--  jsscript.c
new revision: 3.79.2.5.2.6; previous revision: 3.79.2.5.2.5
done

Comment 4

[Brian Crowder]

Adding taras to this bug as an example of a potentially statically-analyzable bad bug.  Basically, the ordering mistake here (getting the script pointer too early) allows the value conversion to destroy the referenced heap data, leaving you with a pointer into bogus memory.  I'm not sure if this really IS statically analyzable, but you might be able to posit some "lint-like" rules (the pointer returned by GetPrivate could be considered untrusted after a variety of JS routines run).