Closed Bug 759283 Opened 12 years ago Closed 12 years ago

IonMonkey: (ARM) Crash trying to execute null near JS::Value::setInt32

Categories

(Core :: JavaScript Engine, defect)

Other Branch
ARM
Linux
defect
Not set
major

Tracking

()

RESOLVED FIXED
Tracking Status
firefox13 - unaffected
firefox14 - unaffected
firefox15 - unaffected
firefox16 - unaffected
firefox-esr10 --- unaffected

People

(Reporter: decoder, Unassigned)

References

Details

(Keywords: crash, sec-critical, testcase)

Attachments

(2 files, 1 obsolete file)

The following testcase crashes on ionmonkey-arm (private branch) revision  (run with --ion -n -m --ion-eager):


function TestCase(n, d, e, a) {};
var SECTION = "15.1.2.5-1";
for ( var CHARCODE = 0; CHARCODE < 256; CHARCODE++ ) {
  new TestCase( SECTION, unescape( "%" + ToHexString(CHARCODE) )  );
}
function ToHexString( n ) {
  var hex = new Array();
  for ( var mag = 1; Math.pow(16,mag) <= n ; mag++ ) {  }
  for ( index = 0, mag -= 1; mag > 0; index++, mag-- ) {
    hex[index] = Math.floor( n / Math.pow(16,mag) );
  }
  hex[hex.length] = n % 16;
  var string ="";
  for ( var index = 0 ; index < hex.length ; index++ ) {
    switch ( hex[index] ) {
    case 10: string += "A"; break;
    case 11: break;
    case 12: break;
    }
  }
}
Crash trace:

Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
(gdb) bt
#0  0x00000000 in ?? ()
#1  0x0000b2fa in JS::Value::setInt32 (this=Cannot access memory at address 0x26
) at ../../jsapi.h:244
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Group: core-security
The backtrace is kind of off, but my hacked-together instruction tracing shows that the last instruction that is executed before 0x0 is
=> 0x40017c18:  ldrpl   pc, [pc, r9, lsl #2]
which looks kind of like gibberish, but is actually the second to last instruction in the sequence
   0x40017c10:  subs    r9, r9, #10
   0x40017c14:  rsbspl  r9, r9, #2
=> 0x40017c18:  ldrpl   pc, [pc, r9, lsl #2]
   0x40017c1c:  b       0x40017d1c
   0x40017c20:                  ; <UNDEFINED> instruction: 0xffff8016
which is the correct sequence for a TableSwitch, but it is followed by a pool header (0xffff8016) rather than a jump table.  This is one of the "edge cases" that I didn't bother to implement due to the infrequency that something like this could occur.
All of the infrastructure was already in place.  It just wasn't being called.
Attachment #627954 - Flags: review?
Summary: IonMonkey: Crash trying to execute null near JS::Value::setInt32 → IonMonkey: (ARM) Crash trying to execute null near JS::Value::setInt32
Comment on attachment 627954 [details] [diff] [review]
/home/mrosenberg/patches/ArmGCKeepJIT-r0.patch

Marty, who should review this?

Drive-by comment: it would be nice to have an RAII pattern for no-pool blocks.
Attachment #627954 - Attachment is obsolete: true
Attachment #627954 - Flags: review?
Attachment #629104 - Flags: review?(dvander)
Comment on attachment 629104 [details] [diff] [review]
now with more RAII

Review of attachment 629104 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks for getting rid of the huge #ifdef

::: js/src/ion/arm/Assembler-arm.h
@@ +1982,5 @@
>          return false;
>      }
>  };
>  
> +class DePooler {

nit: Better name for this is "AutoForbidPools" or something
Attachment #629104 - Flags: review?(dvander) → review+
now that the other patch has landed this patch changes the names to AutoForbidPools, and adds in another couple of uses of it.
Attachment #632509 - Flags: review?(dvander)
Attachment #632509 - Flags: review?(dvander) → review+
landed + fixed: http://hg.mozilla.org/projects/ionmonkey/rev/2531ca245600
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Group: core-security
You need to log in before you can comment on or make changes to this bug.