1432333 - AddressSanitizer: BUS @gfx/skia| @media/libyuv

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect, P3)

Description

[Bob Clary [:bc] (inactive)]

Attachment: Assertion failure: mBuffer local build Fedora

1. https://play.google.com/books/reader?id=EVyuCgAAQBAJ&printsec=frontcover&output=reader&hl=en_US

2. Assertion failure: mBuffer, at /mozilla/builds/nightly/mozilla/gfx/layers/client/ContentClient.cpp:981 with local build 20180120094007 https://hg.mozilla.org/mozilla-central/rev/8b1f0ca44c7be9a15bfbedf0cde540831f2e2aec

or AddressSanitizer: BUS /builds/worker/workspace/build/src/gfx/skia/skia/src/core/SkUtils.cpp:18:19 in sk_memset32(unsigned int*, unsigned int, int) in automation but which I could not reproduce locally.

or Windows 10 64bit where it appears to oom crash.

Not sure that the AddressSanitizer: BUS is security sensitive but I'm marking it as such until someone else can decide whether to keep it that way.

See also bug 1428599

Comment 1

[Bob Clary [:bc] (inactive)]

Attachment: AddressSanitizer: BUS

AddressSanitizer: BUS occurs on both Fedora 27 and Ubuntu 17.10

PS. This is occurring in both Firefox 58 Beta and Firefox 59 Nightly.

Comment 2

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

> Not sure that the AddressSanitizer: BUS is security sensitive but I'm marking it as such until someone else can decide whether to keep it that way.

Do you have any thoughts on how security sensitive this is?

Comment 3

[Christian Holler (:decoder)]

From the trace and the symptoms described that happen on other OSes, I would say this is the combination of an out-of-memory (heap) condition combined with a stack space exhaustion (see also bug 909094, closely related to the "stack clash" vulnerability family). The process is likely receiving SIGBUS because it is trying to call (requiring stack memory) but while allocating that stack memory, it is touching the guard page between stack and heap. Unless the attacker can control the stack allocation (in particular the size) in an exact way (to jump over the guard page), this should not be exploitable. Maybe a skia developer can confirm this theory based on the trace. I was also able to locally reproduce this with an ASan build, simply by visiting the given URL (warning, your machine will go OOM).

Comment 5

[Bob Clary [:bc] (inactive)]

Attachment: url1-asan-opt.txt

https://play.google.com/books/reader?id=oRIA7Peu0uYC&printsec=frontcover&output=reader&hl=en

AddressSanitizer:DEADLYSIGNAL
=================================================================
==15894==ERROR: AddressSanitizer: BUS on unknown address 0x7fc011647000 (pc 0x7fc236d7a075 bp 0x7ffdec72c5a0 sp 0x7ffdec72c558 T0)
    #0 0x7fc236d7a074 in ARGBSetRow_X86 /builds/worker/workspace/build/src/media/libyuv/libyuv/source/row_gcc.cc:3930:3

Comment 6

[Bob Clary [:bc] (inactive)]

Attachment: url1-asan-debug.txt

https://play.google.com/books/reader?id=oRIA7Peu0uYC&printsec=frontcover&output=reader&hl=en

AddressSanitizer:DEADLYSIGNAL
=================================================================
==16156==ERROR: AddressSanitizer: BUS on unknown address 0x7fd129b9f000 (pc 0x7fd34a0b6495 bp 0x7fffa8303580 sp 0x7fffa8303528 T0)
    #0 0x7fd34a0b6494 in ARGBSetRow_X86 /builds/worker/workspace/build/src/media/libyuv/libyuv/source/row_gcc.cc:3930:3

Comment 7

[Bob Clary [:bc] (inactive)]

Attachment: url2-asan-opt.txt

https://play.google.com/books/reader?id=KkYPvx3XKtoC&pg=GBS.PP1

AddressSanitizer:DEADLYSIGNAL
=================================================================
==16478==ERROR: AddressSanitizer: BUS on unknown address 0x7fcf0b95f000 (pc 0x7fd123963120 bp 0x7fd100b16610 sp 0x7fd100b16600 T16)
    #0 0x7fd12396311f in store /builds/worker/workspace/build/src/gfx/skia/skia/src/core/../opts/SkNx_sse.h:280:38

Comment 8

[Bob Clary [:bc] (inactive)]

Attachment: url2-asan-debug.txt

https://play.google.com/books/reader?id=KkYPvx3XKtoC&pg=GBS.PP1

AddressSanitizerAddressSanitizer:DEADLYSIGNAL
:DEADLYSIGNAL
=================================================================
==16758==ERROR: AddressSanitizer: BUS on unknown address 0x7fb2065e0000 (pc 0x7fb47beb6495 bp 0x7ffef6125300 sp 0x7ffef61252a8 T0)
    #0 0x7fb47beb6494 in ARGBSetRow_X86 /builds/worker/workspace/build/src/media/libyuv/libyuv/source/row_gcc.cc:3930:3

Comment 9

[Bob Clary [:bc] (inactive)]

Attachment: url3-asan-opt.txt

https://play.google.com/books/reader?id=SQbUCwAAQBAJ&printsec=frontcover&output=reader&hl=en_GB

AddressSanitizer:DEADLYSIGNAL
=================================================================
==17070==ERROR: AddressSanitizer: BUS on unknown address 0x7f7c138a9000 (pc 0x7f7e2d94e2c4 bp 0x7f7e0aa56610 sp 0x7f7e0aa56600 T16)
    #0 0x7f7e2d94e2c3 in store /builds/worker/workspace/build/src/gfx/skia/skia/src/core/../opts/SkNx_sse.h:280:38

Comment 10

[Bob Clary [:bc] (inactive)]

Attachment: url3-asan-debug.txt

https://play.google.com/books/reader?id=SQbUCwAAQBAJ&printsec=frontcover&output=reader&hl=en_GB

AddressSanitizer:DEADLYSIGNAL
=================================================================
==17342==ERROR: AddressSanitizer: BUS on unknown address 0x7fda31ed8000 (pc 0x7fdc8c537248 bp 0x7fdc2a35d2b0 sp 0x7fdc2a35d2a0 T16)
    #0 0x7fdc8c537247 in (anonymous namespace)::SkNx<4, unsigned int>::store(void*) const /builds/worker/workspace/build/src/gfx/skia/skia/src/core/../opts/SkNx_sse.h:280:38

Comment 11

[Bob Clary [:bc] (inactive)]

63 beta 12
bp-51eaf3fd-048d-4427-9849-9986f0181007
bp-d67d477c-b9f1-4d6d-b409-7053f0181007
bp-f025d6ba-93aa-47fe-853b-f9e8d0181007
release 62.0.3
bp-c066e6b0-46ad-45be-9a68-0cec20181007
bp-7e4da9d8-7f15-44ef-9d58-774040181007
bp-f700f515-182d-4e7d-87d5-68e3e0181007

Comment 12

[Jed Davis [:jld] ⟨⏰|UTC-8⟩ ⟦he/him⟧]

This looks like bug 1245239: /dev/shm is out of space, so a write to a previously sparse shared memory file fails with ENOSPC, but the write is via a page fault so that raises SIGBUS.

Specifically, the stacks suggest the graphics code is writing to shared memory to pass image data to the parent, SIGBUS indicates I/O errors on memory-mapped files and not much else, and the “Failed buffer” messages that appear in some of the logs strongly suggest that the error is ENOSPC.  Also, notice that all the crashes reported here are page-aligned, which is consistent with some loop writing to the file and failing when it causes a page allocation.

This could be confirmed by catching the crash in a debugger, checking the free space on /dev/shm, and verifying that the crash address is in-bounds for a file in /dev/shm (by checking /proc/N/maps).  Also, the crashing instruction would be part of something that's storing graphics data, not a call or stack spill (cf. comment #3).

Comment 13

[Bob Clary [:bc] (inactive)]

My debugger fu is not adequate these days but if this is not security sensitive and is the same as bug 1245239 as I suspected, I would appreciate it if someone who is better qualified to do so would a) remove the security-sensitive flag and b) dupe to bug 1245239. Perhaps we can get movement there. The fact that this happens on the the play store is problematic in my opinion. One reliable way to push someone to use a different browser is to continually crash on one of their favorite sites.

Comment 14

[Jed Davis [:jld] ⟨⏰|UTC-8⟩ ⟦he/him⟧]

I visited the repro URL on a machine with a lot of RAM; it did load without crashing, but it consumed 22.8 GiB of shared memory.

So there is a bug here, because that's more memory than almost all of the computers that run Firefox even have, but it appears to just be an OOM so I don't think it needs to be hidden as security-sensitive.  (I'm not in the graphics security group, just cc'ed on the bug, so I can't reclassify it.)

Also, this isn't a dup of bug 1245239: even if we used memfd_create on Linux (bug 1440203) and shared memory were accounted like anonymous mmap, the equivalent of malloc()ing that much memory will still cause a normal OOM (like the Windows OOM mentioned in comment #0).

Comment 15

[BugBot [:suhaib / :marco/ :calixte]]

Closing because no crashes reported for 12 weeks.

Comment 16

[Bob Clary [:bc] (inactive)]

fwiw, this still occurs. reopening.

Comment 17

[BugBot [:suhaib / :marco/ :calixte]]

Closing because no crashes reported for 12 weeks.

Comment 18

[Bob Clary [:bc] (inactive)]

This is still reproducible.

Comment 19

[BugBot [:suhaib / :marco/ :calixte]]

Closing because no crashes reported for 12 weeks.

Comment 20

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug is a regression, but please revert this change in case of error.