Closed
Bug 1500064
Opened 6 years ago
Closed 6 years ago
IdSet in enumeration code needs to be rooted
Categories
(Core :: JavaScript: GC, enhancement, P1)
Core
JavaScript: GC
Tracking
()
RESOLVED
FIXED
mozilla64
People
(Reporter: jandem, Assigned: jandem)
Details
(Keywords: csectype-disclosure, sec-moderate, Whiteboard: [post-critsmash-triage][adv-main64+])
Attachments
(1 file)
This is a Maybe<IdSet> and IdSet is a HashSet<jsid, ...>
Because (1) we can call arbitrary code while this set is on the stack (via scripted proxy traps, so content can trigger a GC etc) and (2) not all ids in the set are guaranteed to exist elsewhere (the |props| Vector contains a subset), this seems to be a rooting hazard.
The simplest option is probably to make this a GCHashSet. A bit unfortunate for me because I wanted to make this an InlineSet but oh well. We could add GCInlineSet later maybe.
Assignee | ||
Comment 1•6 years ago
|
||
I'm not sure how s-s this is because we only use this set to check whether we've already seen a particular id. OTOH, it might be possible to leak info like "is any origin using atom x?" or something.
Updated•6 years ago
|
Priority: -- → P1
Updated•6 years ago
|
Keywords: csectype-disclosure,
sec-moderate
Comment 2•6 years ago
|
||
Note that bug 1321014 will fix the part about the hazard analysis not seeing through the Maybe<> to report this problem. I think it may require further annotation to get it to complain about the HashSet, though, since HashSet contains a table of type js::detail::HashTableEntry<const jsid>*. That won't be treated as a GC pointer type because (1) it's a pointer to a GC pointer, and (2) HashTableEntry contains untyped data (uint8[8] in this case). But I should be able to use MOZ_INHERIT_TYPE_ANNOTATIONS_FROM_TEMPLATE_ARGS or something like it to see all the way through to the hazard.
I filed bug 1500247.
Assignee | ||
Updated•6 years ago
|
Assignee: nobody → jdemooij
Status: NEW → ASSIGNED
Assignee | ||
Comment 3•6 years ago
|
||
This changes Maybe<IdSet> to Rooted<IdSet>. I think the Maybe<>
is not buying us much because HashTable's storage is now lazily
allocated (bug 1481998). I didn't notice any regressions in
micro-benchmarks; this patch might be a small improvement actually.
Assignee | ||
Comment 4•6 years ago
|
||
Comment 5•6 years ago
|
||
Group: javascript-core-security → core-security-release
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
status-firefox64:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla64
Comment 6•6 years ago
|
||
Is this something we're going to want to backport to ESR60 during the next cycle for 60.4?
status-firefox62:
--- → wontfix
status-firefox63:
--- → wontfix
status-firefox-esr60:
--- → affected
tracking-firefox-esr60:
--- → ?
Flags: needinfo?(jdemooij)
Assignee | ||
Comment 7•6 years ago
|
||
(In reply to Ryan VanderMeulen [:RyanVM] from comment #6)
> Is this something we're going to want to backport to ESR60 during the next
> cycle for 60.4?
Probably not because (1) I still think the sec-moderate rating is correct and (2) the patch depends on some HashSet changes that are not in ESR60 (bug 1481998) and so the ESR60 patch would either have to be rewritten or regress perf.
Updated•6 years ago
|
Flags: qe-verify-
Whiteboard: [post-critsmash-triage]
Updated•6 years ago
|
Whiteboard: [post-critsmash-triage] → [post-critsmash-triage][adv-main64+]
Updated•5 years ago
|
Group: core-security-release
You need to log in
before you can comment on or make changes to this bug.
Description
•