1273701 - pixman image ref-counting races with cairo solid colors

Status: RESOLVED FIXED

(Core :: Graphics: Layers, defect)

Description

[Karl Tomlinson (:karlt)]

https://cgit.freedesktop.org/cairo/commit/?id=71e8a4c23019b01aa43b334fcb2784c70daae9b5
https://bugs.freedesktop.org/show_bug.cgi?id=

pixman_image_t has virtual function pointers, making use after free serious, but triggering the race is likely difficult.

Comment 1

[Karl Tomlinson (:karlt)]

Attachment: debug session highlights

Comment 2

[Karl Tomlinson (:karlt)]

Attachment: don't reuse pixman images when not thread-safe

https://treeherder.mozilla.org/#/jobs?repo=try&revision=f064f419ca59

Comment 3

[Karl Tomlinson (:karlt)]

Comment on attachment 8753622 [details] [diff] [review]
don't reuse pixman images when not thread-safe

[Security approval request comment]
> How easily could an exploit be constructed based on the patch?
Difficult but conceivable.  An increment needs to be run concurrently with a decrement and these can only happen on main and compositor threads afaik.
Content would need to control the content of an allocation very soon after the refcount decrement, but that could be done on a worker thread.  The |cache| variable provides opportunity to retry continually until success.

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

> Which older supported branches are affected by this flaw?
All of them.

> If not all supported branches, which bug introduced the flaw?
Bug dates back to bug 562746 at least.

> Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be?
The code has not changed much so backports are not difficult.

> How likely is this patch to cause regressions; how much testing does it need?
Unlikely.  It just removes some reuse of objects, instead now creating a new object each time.

Comment 4

[Karl Tomlinson (:karlt)]

(In reply to Karl Tomlinson (ni?:karlt) from comment #3)
> [Security approval request comment]
> > If not all supported branches, which bug introduced the flaw?
> Bug dates back to bug 562746 at least.

Sorry, that's not correct.  The bug was introduced with OMTC, bug 899785.

Comment 5

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

sec-approval+ for trunk. I'd like to get a patch nominated for Aurora, Beta, and ESR45 as well.

Comment 6

[Karl Tomlinson (:karlt)]

Comment on attachment 8753622 [details] [diff] [review]
don't reuse pixman images when not thread-safe

Approval Request Comment
[Feature/regressing bug #]:
Bug 899785.
[User impact if declined]:
Random crash (bug 1268202), potentially exploitable.
[Describe test coverage new/current, TreeHerder]:
No new test.  Exploiting the race would require careful timing or brute force.
Code is widely used and so exercised by existing tests.
[Risks and why]: 
Unlikely.  The patch just removes some reuse of objects, instead now creating a new object each time.
[String/UUID change made/needed]:
None

[Approval Request Comment]
Fix Landed on Version: 49

Comment 7

[Karl Tomlinson (:karlt)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/fb131a07c5bc

Comment 8

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8753622 [details] [diff] [review]
don't reuse pixman images when not thread-safe

Sec-high, Aurora48+, Beta47+, ESR45+

Comment 9

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/releases/mozilla-beta/rev/256e89214e18

Comment 10

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/94a3ac0c8c86
https://hg.mozilla.org/releases/mozilla-esr45/rev/28dcecced055

Comment 11

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/fb131a07c5bc