Faulty: crash in free() under _moz_pixman_region32_copy under nsRegion::Copy under LayerTransactionParent::RecvUpdate

RESOLVED FIXED in Firefox 30

Status

()

RESOLVED FIXED
5 years ago
3 years ago

People

(Reporter: bjacob, Assigned: bjacob)

Tracking

(Blocks: 1 bug, {sec-critical})

Trunk
mozilla30
x86_64
Linux
sec-critical
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox27 wontfix, firefox28 disabled, firefox29 disabled, firefox30+ fixed, firefox-esr24 unaffected)

Details

(Whiteboard: [qa-])

Attachments

(2 attachments)

Created attachment 8370306 [details]
Faulty session

Found by Christoph Diehl's "Faulty" fuzzer, see bug 777067
(Assignee)

Comment 1

5 years ago
free() crashes are often double frees, but here, see the GDB session attached, this doesn't look like already-freed memory. So I don't know what to make of this.
Group: core-security
(Assignee)

Comment 2

5 years ago
Note: found while running css-blending reftests.
Sounds memory-corruptiony.  Can you run the Faulty fuzzer with ASAN?
(Assignee)

Comment 4

5 years ago
Should be trivial, since the fuzzer is orthogonal to compiler or memory allocator considerations.

Remind me how to enable ASAN?
(Assignee)

Comment 6

5 years ago
Thanks; my future reports will be with an ASAN build.
(Assignee)

Comment 7

5 years ago
Classification: PLayerTransactionParent, memory corruption, hard.
(Assignee)

Comment 8

5 years ago
Created attachment 8370927 [details]
Another session, with ASan
(Assignee)

Comment 9

5 years ago
Andrew, the new log says it's using ASan at the top, and there is __asan::AsanThread::ThreadStart in the crash callstack, so I assume that ASan is taking effect here. Does this tell you anything? Did I have to do something different?
(Assignee)

Updated

5 years ago
Flags: needinfo?(continuation)
#1  0x00002aaab488c400 in nsRegion::Copy (this=0x617000214cd8, aRegion=...) at ../../dist/include/nsRegion.h:260
260         pixman_region32_copy(&mImpl, aRegion.Impl());
(gdb) p mImpl
$3 = {extents = {x1 = 0, y1 = 0, x2 = 0, y2 = 0}, data = 0x3ff0000000000000}
(gdb) p aRegion.Impl()
$4 = (pixman_region32_t *) 0x62100088138c
(gdb) p *aRegion.Impl()
$5 = {extents = {x1 = 0, y1 = 0, x2 = 0, y2 = 0}, data = 0x2aaad4b87040}
Er, this looks like a bad pointer:

(gdb) p mImpl.data
$6 = (pixman_region32_data_t *) 0x3ff0000000000000

Looks like either something scribbled a region we're passing to pixman, or we're reinterpreting something else as a region.
Classification: PLayerTransaction, memory corruption, hard
Hmm.  Yeah, that is certainly not producing an ASAN report.  Maybe running it under the debugger interferes with how ASAN deals with a SIGSEV?  Maybe decoder has some idea?

An ASAN report will start out looking more like

==5650==ERROR: AddressSanitizer: heap-use-after-free on address 0xwhatever at pc [...]
READ of size 8 at 0xsomething thread T0
Flags: needinfo?(continuation) → needinfo?(choller)
Ah, sure, GDB is catching the segfault before ASan can.

But the above session still shows that there is no ASan-caught memory corruption before we crash, right?
Yeah, it sounds like it isn't a use-after-free at least, and we're just accessing some kind of garbage.
(Assignee)

Updated

5 years ago
Depends on: 968833
It's certainly possible to crash without triggering any ASan mechanisms other than ASan's internal SIGSEGV handler (which will not be triggered if GDB catches the signal first). This will for example happen if we directly access a memory address that is not accessible but also has never been accessible before (so ASan doesn't consider it uaf or anything else).
Flags: needinfo?(choller)
Sounds bad.  Assigning to bjacob as he seems to be looking at the blocking bug already.
Assignee: nobody → bjacob
Keywords: sec-critical
status-firefox27: --- → ?
status-firefox28: --- → ?
status-firefox29: --- → ?
status-firefox30: --- → affected
status-firefox-esr24: --- → unaffected
tracking-firefox30: --- → +
Fixed by the landing of PLayerTransaction type checks before casting layers, bug 968833.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
status-firefox27: ? → wontfix
status-firefox28: ? → affected
status-firefox29: ? → affected
status-firefox30: affected → fixed
Target Milestone: --- → mozilla30
Benoit, is this one of the fixes that you don't think makes sense to take on Aurora and Beta?
Yes, so do generally all blockers (or blockers of blockers) of bug 963790.
status-firefox28: affected → disabled
status-firefox29: affected → disabled
Marking [qa-] for verification, lack of test case.
Whiteboard: [qa-]
Group: core-security
You need to log in before you can comment on or make changes to this bug.