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)
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.
=============================================================
Comment 1•8 years ago
|
||
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
Updated•8 years ago
|
Priority: -- → P1
Comment 2•8 years ago
|
||
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)
Updated•8 years ago
|
Updated•8 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 3•8 years ago
|
||
(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)
Comment 5•8 years ago
|
||
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)
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
Updated•7 years ago
|
Whiteboard: [#jsapi:crashes-retriage]
Comment 7•7 years ago
|
||
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
Comment 8•5 years ago
|
||
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]
Updated•1 year ago
|
Group: javascript-core-security
You need to log in
before you can comment on or make changes to this bug.
Description
•