1322971 - Cell iterators need a read barrier

Status: RESOLVED FIXED

(Core :: JavaScript: GC, defect)

Description

[Jon Coppeard (:jonco)]

Iterating through allocated cells can hand out pointers to otherwise unreachable cells, and so needs a read barrier in case there's an incremental GC going on.

This came up originally in bug 1322420.

Comment 1

[Jon Coppeard (:jonco)]

Attachment: bug1322420-barrier-cell-iter

Patch to add a barrier to AreanCellIter.  ArenaCellIterImpl is used both during and outside of GC so this needs a dynamic check.  It does a full ExposeToActiveJS as we can find gray things in the heap and then hand them back to the caller.

Comment 2

[Frederik Braun [:freddy] (out until Feb 6th)]

Hey Steve, this is a security issue. Can you please move this review request to the top of your pile?
If not, please redirect to someone else ASAP (and make sure they do have the time!)

Comment 3

[Steve Fink [:sfink] [:s:]]

Comment on attachment 8830414 [details] [diff] [review]
bug1322420-barrier-cell-iter

Review of attachment 8830414 [details] [diff] [review]:
-----------------------------------------------------------------

Sorry for the delay. I don't have a great system for secure bugs, it seems. Please ping after 48 hours.

Comment 4

[Jon Coppeard (:jonco)]

Comment on attachment 8830414 [details] [diff] [review]
bug1322420-barrier-cell-iter

[Security approval request comment]
How easily could an exploit be constructed based on the patch?

Very difficult.

Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?

No.

Which older supported branches are affected by this flaw?

At least as far back as 32.

If not all supported branches, which bug introduced the flaw?

Bug 1001159 introduced this class but the flaw may have been present before then.

Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be?

It may require rebasing but the result shouldn't be very different.

How likely is this patch to cause regressions; how much testing does it need?

Unlikely.

Comment 5

[Al Billings [:abillings - ex-MoCo]]

sec-approval+ for trunk.
We'll want this on affected branches as well if you can nominate patches.

Comment 6

[Jon Coppeard (:jonco)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/4e919ac282a4b42906d8695a0e1671e8ec2a044c

Comment 7

[Frederik Braun [:freddy] (out until Feb 6th)]

Jon, can you please nominate branch patches for all other affected branches?

Comment 8

[Jon Coppeard (:jonco)]

I mistakenly landed this with the wrong bug number:

https://hg.mozilla.org/mozilla-central/rev/4e919ac282a4

Comment 9

[Jon Coppeard (:jonco)]

Attachment: bug1322971-backport

Approval Request Comment
[Feature/Bug causing the regression]: Bug 1001159.
[User impact if declined]: Possible crash / security violation.
[Is this code covered by automated tests?]: Yes.
[Has the fix been verified in Nightly?]: Yes.
[Needs manual test from QE? If yes, steps to reproduce]: No.
[List of other uplifts needed for the feature/fix]: None.
[Is the change risky?]: No.
[Why is the change risky/not risky?]: This is a fairly simple change that adds a read barrier when iterating cells in arenas.
[String changes made/needed]: None.

Comment 10

[Jon Coppeard (:jonco)]

Attachment: bug1322971-esr45

[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration: sec-high bug.
User impact if declined: Possible crash / security vulnerability.
Fix Landed on Version: 54.
Risk to taking this patch (and alternatives if risky): Low.
String or UUID changes made by this patch: None.

Comment 11

[Al Billings [:abillings - ex-MoCo]]

Comment on attachment 8837584 [details] [diff] [review]
bug1322971-backport

Approving for Beta and Aurora. I'll wait for release management to make a decision for ESR45.

Comment 12

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/d956e48d28df
https://hg.mozilla.org/releases/mozilla-beta/rev/6e2dcde91b89

Comment 13

[Gerry Chang [:gchang]]

Comment on attachment 8837594 [details] [diff] [review]
bug1322971-esr45

Fix a sec-high. ESR45+.

Comment 14

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr52/rev/6e2dcde91b89
https://hg.mozilla.org/releases/mozilla-esr45/rev/a0ead6ef09eb

Comment 15

[Andrei Vaida [:avaida]]

Setting qe-verify- based on Jon's assessment on manual testing needs (Comment 9) and the fact that this fix has automated coverage.