Closed Bug 1329042 Opened 8 years ago Closed 5 years ago

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

Categories

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

50 Branch
x86
Windows 7
defect

Tracking

()

RESOLVED INVALID

People

(Reporter: yourbiz2011, Unassigned)

References

Details

(4 keywords)

Crash Data

This bug was filed from the Socorro interface and is report bp-a4a8b0f3-58ca-4723-b454-f85982170105. =============================================================
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.
Group: firefox-core-security → javascript-core-security
Component: Activity Streams: Application Servers → JavaScript Engine: JIT
Product: Firefox → Core
Priority: -- → P1
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?
Flags: needinfo?(jcoppeard)
Status: UNCONFIRMED → NEW
Ever confirmed: true
(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.
Flags: needinfo?(jcoppeard)
Should I move this to the GC category?
Flags: needinfo?(jcoppeard)
I didn't see anything to indicate that this is a GC bug; having said that it didn't make much sense at all.
Flags: needinfo?(jcoppeard)
See Also: → 1036779
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 '--'.
Keywords: stale-bug
Whiteboard: [#jsapi:crashes-retriage]
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.
Priority: P1 → P2

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.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → INVALID
Whiteboard: [#jsapi:crashes-retriage]
Group: javascript-core-security
You need to log in before you can comment on or make changes to this bug.