1329042 - Crash in memset | js::jit::ExecutableAllocator::poisonCode

Status: RESOLVED INVALID

(Core :: JavaScript Engine: JIT, defect, P2)

Description

[howard]

This bug was filed from the Socorro interface and is 
report bp-a4a8b0f3-58ca-4723-b454-f85982170105.
=============================================================

Comment 1

[Daniel Veditz [:dveditz]]

Crashes at this location were close to non-existent until August, really picked up at the end of September, and then went up a bit more late November. That could reflect Firefox 50 working its way through the development cycle, but I see crashes going back to Firefox 47 builds.

We're trying to write to memory we don't own which is never good. But it's a fixed poison value over a big chunk so you'd have to be super clever to figure out a way to exploit that.

Comment 2

[Hannes Verschore [:h4writer]]

I would say it started having an increased volume in FF49. I can't really read much into it.
@Jon: can you deduce more out of these crashes. Has anything changed in FF49 that might explain this increase that you know about?

Comment 3

[Jon Coppeard (:jonco)]

(In reply to Hannes Verschore [:h4writer] from comment #2)
I couldn't see anything.

The second fix in bug 1264300 is the right general area and timeframe but I couldn't see how it would cause this.

Comment 4

[Hannes Verschore [:h4writer]]

Should I move this to the GC category?

Comment 5

[Jon Coppeard (:jonco)]

I didn't see anything to indicate that this is a GC bug; having said that it didn't make much sense at all.

Comment 6

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

This is a P1 bug without an assignee. 

P1 are bugs which are being worked on for the current release cycle/iteration/sprint. 

If the bug is not assigned by Monday, 28 August, the bug's priority will be reset to '--'.

Comment 7

[Nicolas B. Pierron [:nbp]]

This bug does not seems actionable at the moment.
I see some UAF which seems to suggests that JitPoisonRangeVector got corrupted content and we are reading from it.

Comment 8

[Ted Campbell [:tcampbell]]

Using my minidump tool, I'm able to determine the range of legal JIT code executable memory, and the current protection status of each page in it. It is also straightforward to look at the start-ptr and buffer-length arguments for the memset itself. For all the samples I looked at, either the size had a bit flipped (eg. 0x000000b0 -> 0x002000b0) or the start-ptr had a bit flip that moved it out of range from a currently-writable page in jit memory.

This is just general bad hardware / memory corruption.