808349 - Crash with mjitChunkLimit, verifyprebarriers

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Jesse Ruderman]

Attachment: testcase

1. Install https://www.squarefree.com/extensions/domFuzzLite3.xpi
2. Load the testcase.

Result: Crash in mjit-generated code

(Why does the mozRequestAnimationFrame call matter?  That seems to be all that prevents this testcase from running in the shell.)

Comment 1

[Jesse Ruderman]

Attachment: stack

Comment 2

[Andrew McCreight [:mccr8]]

Marking sec-crit because these chunk limit things seem to end up with that rating, and crashing in mjit code sounds sketchy, until proven otherwise. Feel free to adjust as needed.

Comment 3

[Robert Kaiser]

This is a sec-crit with a testcase, and it's marked tracking for 19.
Naveed, could we get some traction here?

Comment 4

[Robert Kaiser]

(In reply to Robert Kaiser (:[e-mail]) from comment #3)
> This is a sec-crit with a testcase, and it's marked tracking for 19.
> Naveed, could we get some traction here?

Ping?

Also, this seems to be a js::mjit::EnterMethodJIT crash, and this signature is pretty common, so it's possible we see this security issue in the wild and not realize it at all.

Comment 5

[David Anderson [:dvander] - inactive, e-mail if emergency]

Brian, judging by the test this looks like another chunk compilation edge-case bug. Is this something you could look at? Or maybe a better question is: is there anything we could do to mitigate chunked compilation bugs while we wait for baseline compilation?

Comment 6

[Nicolas B. Pierron [:nbp]]

(In reply to Jesse Ruderman from comment #0)
> Created attachment 678078 [details]
> testcase
> 
> 1. Install https://www.squarefree.com/extensions/domFuzzLite3.xpi
> 2. Load the testcase.
> 
> Result: Crash in mjit-generated code
> 
> (Why does the mozRequestAnimationFrame call matter?  That seems to be all
> that prevents this testcase from running in the shell.)

mozRequestAnimationFrame set a flag which is used to preserve code on GCs.  Without this flag the code would be GCed and the bug will not appear.

Comment 7

[Nicolas B. Pierron [:nbp]]

Comment on attachment 678078 [details]
testcase

Try to replace

  window.mozRequestAnimationFrame(function() {});

by

  gcPreserveCode();
  (function(){})();

Comment 8

[Brian Hackett [Laid off!]]

Attachment: fix mjitChunkLimit()

This is a bug in the mjitChunkLimit() test function.  mjitChunkLimit() is only intended to be called if the JS_GC it does to clear out jitcode actually does clear out jitcode.  It already checked for the effects of gcPreserveCode() which will prevent clearing jitcode in the shell, but not the animation information which will prevent clearing jitcode in the browser.  The attached patch should fix this.

Comment 9

[Josh Aas]

Is this actually a sec-critical bug? Still says so in the keywords. I assume you cleared the core-security flag because it isn't?

Comment 10

[Andrew McCreight [:mccr8]]

Judging from the patch, this is a bug in a testing-only function.

Comment 11

[Brian Hackett [Laid off!]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/bce6a584bc0f

Comment 12

[(no longer active)]

https://hg.mozilla.org/mozilla-central/rev/bce6a584bc0f