Hazard Introduced by SourceExtent
Categories
(Core :: JavaScript Engine, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr68 | --- | unaffected |
firefox73 | --- | unaffected |
firefox74 | --- | unaffected |
firefox75 | --- | fixed |
People
(Reporter: mgaudet, Assigned: mgaudet)
References
(Regression)
Details
(Keywords: csectype-uaf, regression, sec-high, Whiteboard: [post-critsmash-triage])
Attachments
(1 file)
It appears that as part of my SourceExtent Patch (Bug 1615728) I introduced a GC hazard
The issue is as follows:
- In
JSScript::CreateFromLazy
we callJSScript::New(cx, fun, sourceObject, lazy->extent())
;lazy->extent()
returns a reference to the memberextent_
of the correctly rootedLazyScript lazy
. - Inside
JSScript::New
we callAllocate
, then invoke theJSScript
constructor on the returned memory, with theextent
reference that was passed in. - When
Allocate
is called,lazy
gets moved; and the reference now points to deallocated memory.
I'm going to mark this as a secure bug; I'm not entirely sure of the security implications here, and given it's only been on nightly for less than 24 hours it's not high sev, but it's an issue.
Assignee | ||
Comment 1•4 years ago
|
||
On my local build I can reproduce this trivally by running central with the anyref-val-tracing
test.
Assignee | ||
Comment 2•4 years ago
|
||
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Comment 3•4 years ago
|
||
For the few times we return references or pointers to fields of GC things, the quick & dirty technique is to change the accessor signature to require an AutoRequireNoGC& parameter. It doesn't fully prevent problems, but at least makes the caller create (probably) an AutoCheckCannotGC on the stack and thus think about the live range and where GC is possible.
...but of course, you have to know about the potential for problems in order to know to do something like that, and I've got nothing for that.
(And your fix here is definitely better; if you can get away with copying, it's safer and easier to use.)
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 4•4 years ago
|
||
I opened Bug 1616926 as a potential road for us to get a simple static analysis that helps prevent cases like this.
Assignee | ||
Comment 5•4 years ago
|
||
Updated•4 years ago
|
Comment 6•4 years ago
|
||
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Description
•