AddressSanitizer: heap-use-after-free [@ ~BorrowedSourceSurface] with READ of size 8
Categories
(Core :: Graphics, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr68 | --- | unaffected |
firefox-esr78 | --- | unaffected |
firefox78 | --- | unaffected |
firefox79 | + | wontfix |
firefox80 | + | wontfix |
firefox81 | + | fixed |
firefox82 | + | fixed |
People
(Reporter: decoder, Assigned: jgilbert)
References
(Regression)
Details
(5 keywords, Whiteboard: [sec-survey][post-critsmash-triage][adv-main81+])
Crash Data
Attachments
(3 files, 1 obsolete file)
22.60 KB,
text/plain
|
Details | |
47 bytes,
text/x-phabricator-request
|
tjr
:
approval-mozilla-beta+
tjr
:
sec-approval+
|
Details | Review |
209 bytes,
text/plain
|
Details |
The attached crash information was submitted via the ASan Nightly Reporter on mozilla-central-asan-nightly revision 80.0a1-20200719090414-https://hg.mozilla.org/mozilla-central/rev/e785ebabf7e142898e31a6c81a4d43d44eff39e3.
For detailed crash information, see attachment.
Reporter | ||
Comment 1•5 years ago
|
||
Reporter | ||
Updated•5 years ago
|
Comment 3•5 years ago
|
||
This was discovered on Fedora 31, this box has an Nvidia RTX 2070 with the official 440.100 drivers. Window manager is xfce4. The following extra configuration options are set if it makes a difference:
gfx.webrender.all = true
fission.autostart = true
image.avif.enabled = true
No other information to share as this seems to have been found while randomly browsing the web. If I can trigger this again, I'll keep notes.
Updated•5 years ago
|
Comment 4•5 years ago
|
||
This crash appears to be in code added in a WebGL refactor for out-of-process (bug 1632249), so that puts a lower limit on affected versions at 79, though this could be a more recent regression. mReturnTo
is a raw pointer so apparently the borrowed surface is outliving the "persistent" buffer somehow.
Comment 5•5 years ago
|
||
Crashes start in the 20200611093454 build which would be consistent to when bug 1632249 was checked in. bug 1646408 was filed on the regressing signature but not tagged as a security bug. Although Linux crashes look like null derefs, Windows ones are clearly UAF -- rax is 0xe5e5e5e5e5e5e5e5
. for example bp-e922e421-30e8-49dc-9a5a-ee5230200703
[Tracking Requested - why for this release]:
I'm sure this is way too late for 79--haven't even started looking at a fix--but wanted to flag it for visibility since it's a security regression in that release.
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Comment 7•5 years ago
|
||
tracking+ for 79, but yeah, probably too late to get it fixed except maaaaybe in a dot release :(
Updated•4 years ago
|
Comment 8•4 years ago
|
||
Any updates Jeff? We're about to build the last beta for 80.
Updated•4 years ago
|
Assignee | ||
Comment 9•4 years ago
|
||
Assignee | ||
Comment 10•4 years ago
|
||
Comment on attachment 9171792 [details]
Bug 1654211 - Hold WeakPtr to PresistentBufferProvider in BorrowedSourceSurface.
Security Approval Request
- How easily could an exploit be constructed based on the patch?: Hard: An attacker would need to construct a situation that replaced the PresistentBufferProvider's memory with something else, such that this call to
PresistentBufferProvider->ReturnSnapshot(surf)
causes an issue. - 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?: 79+
- If not all supported branches, which bug introduced the flaw?: Bug 1632249
- Do you have backports for the affected branches?: Yes
- If not, how different, hard to create, and risky will they be?: Should be trivial.
- How likely is this patch to cause regressions; how much testing does it need?: Low chance for regressions for this very targeted fix.
Updated•4 years ago
|
Comment 11•4 years ago
|
||
Comment on attachment 9171792 [details]
Bug 1654211 - Hold WeakPtr to PresistentBufferProvider in BorrowedSourceSurface.
Approved to land and uplift
Comment 12•4 years ago
|
||
Comment 13•4 years ago
|
||
uplift |
Comment 14•4 years ago
|
||
Updated•4 years ago
|
Comment 15•4 years ago
|
||
Jeff, can we resolve bug 1646408 with this one fixed?
Assignee | ||
Comment 16•4 years ago
|
||
(In reply to Frederik Braun [:freddy] from comment #15)
Jeff, can we resolve bug 1646408 with this one fixed?
Yes, but how and when? (given that this is a sec bug not fixed in all versions)
Comment 17•4 years ago
|
||
As part of a security bug pattern analysis, we are requesting your help with a high level analysis of this bug. It is our hope to develop static analysis (or potentially runtime/dynamic analysis) in the future to identify classes of bugs.
Please visit this google form to reply.
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Comment 19•4 years ago
|
||
Comment 20•4 years ago
|
||
Updated•4 years ago
|
Comment 21•4 years ago
|
||
Can you update the alias of this bug to CVE-2020-15675 and update the alias of bug 1660211 to CVE-2020-15678? I think they got flipped around. Thanks!
Updated•4 years ago
|
Updated•8 months ago
|
Description
•