Closed Bug 967808 Opened 6 years ago Closed 6 years ago

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


(Core :: Graphics, defect)

Not set



Tracking Status
firefox27 --- wontfix
firefox28 --- disabled
firefox29 --- disabled
firefox30 + fixed
firefox-esr24 --- unaffected


(Reporter: bjacob, Assigned: bjacob)


(Blocks 1 open bug)


(Keywords: sec-critical, Whiteboard: [qa-])


(2 files)

Attached file Faulty session
Found by Christoph Diehl's "Faulty" fuzzer, see bug 777067
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
Note: found while running css-blending reftests.
Sounds memory-corruptiony.  Can you run the Faulty fuzzer with ASAN?
Should be trivial, since the fuzzer is orthogonal to compiler or memory allocator considerations.

Remind me how to enable ASAN?
Thanks; my future reports will be with an ASAN build.
Classification: PLayerTransactionParent, memory corruption, hard.
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?
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
$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.
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
Fixed by the landing of PLayerTransaction type checks before casting layers, bug 968833.
Closed: 6 years ago
Resolution: --- → FIXED
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.
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.