Opus crash illegal instruction [@quant_band]

VERIFIED FIXED in Firefox 15

Status

()

Core
Audio/Video
--
critical
VERIFIED FIXED
5 years ago
5 years ago

People

(Reporter: posidron, Assigned: derf)

Tracking

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

unspecified
mozilla15
x86_64
Mac OS X
crash, sec-critical, testcase
Points:
---
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(firefox15+ fixed, firefox16+ fixed, firefox-esr10 unaffected)

Details

(Whiteboard: [asan])

Attachments

(3 attachments)

(Reporter)

Description

5 years ago
Created attachment 619537 [details]
testcase

Reproducible in ASAN builds. Due to a bug in ASAN it is right now not possible to provide values for the functions.
(Reporter)

Comment 1

5 years ago
Created attachment 619538 [details]
callstack
(Assignee)

Comment 2

5 years ago
Haven't investigated too deeply, but this file does not crash opusdec (available from opus-tools: http://git.xiph.org/?p=users/greg/opus-tools.git).
(Reporter)

Comment 3

5 years ago
Sorry, should have mentioned that I have deactivated the checksum verification inside the source.
(Assignee)

Comment 4

5 years ago
(In reply to Christoph Diehl [:cdiehl] from comment #3)
> Sorry, should have mentioned that I have deactivated the checksum
> verification inside the source.

Yes, I ran it through rogg_crcfix. opusdec reported "Decoding error: corrupt stream" in a few places, but did not crash.
(Reporter)

Comment 5

5 years ago
This bug has [asan] in whiteboard. You will need to test it with an ASAN build of Firefox or compile the decoder with ASAN.
(Assignee)

Comment 6

5 years ago
(In reply to Christoph Diehl [:cdiehl] from comment #5)
> This bug has [asan] in whiteboard. You will need to test it with an ASAN
> build of Firefox or compile the decoder with ASAN.

That doesn't change the results. It also ran clean under valgrind with memcheck, exp-ptrcheck, and exp-sgcheck.
The only other thing I can think of is trying with different allocators and even trying with the pseudo-stack and ENABLE_VALGRIND.
(Reporter)

Comment 8

5 years ago
I would recommend compiling a Firefox version with ASAN enabled on MacOSX. This is my environment. The bug itself is reproducible every time. Except that I have commented out the "goto" in https://hg.mozilla.org/mozilla-central/file/40455cbb1ad3/media/libogg/src/ogg_framing.c#l701 nothing was touched.
(Assignee)

Comment 9

5 years ago
(In reply to Christoph Diehl [:cdiehl] from comment #8)
> I would recommend compiling a Firefox version with ASAN enabled on MacOSX.

Yes, that's probably the best idea. But since it doesn't look like the decoder state is getting corrupted by libopus itself (or it would happen in opusdec, also), I think this is rillian's bug to track down.
(Reporter)

Updated

5 years ago
Blocks: 750714
Assignee: nobody → giles
I have an ASAN OS X build from Monday, 4/30, and I get no crash with the attached testcase. I see a playback slider appear momentarily, which then goes away. No errors show up in console output.
(Reporter)

Comment 11

5 years ago
Did you comment out the goto clause?
No, I did not. I'm using a "standard" ASAN build with no changed to pulled source. This only happens if you comment out a clause?
(Reporter)

Comment 13

5 years ago
You will also need to apply the Opus patches from here: https://bugzilla.mozilla.org/show_bug.cgi?id=674225
I think I'll just wait for someone to fix the bug since it is assigned. :-)
That's fine. I don't have an asan build yet though.

Which llvm/clang/compiler-rt revision are you using?
(Reporter)

Comment 16

5 years ago
https://developer.mozilla.org/en/Building_Firefox_with_Address_Sanitizer
In case of problems/info ping the author "decoder", he is also our ASAN maintainer.
Ok, I'm able to reproduce now, thanks to help from decoder, and no thanks to xcode version skew.
Ralph, is this crash exploitable? We can't tell much from the callstack.
I don't know, but given the illegal instruction, the stack's probably corrupted. Which would mean yes.
(Assignee)

Comment 20

5 years ago
Okay, so I was finally able to get an ASAN build going on this aging MacBook loaner.

I think all of the ASAN crashes are simply stack overflows. Opus uses a fair amount of stack (a few dozen kB) and the decoder threads are all created with a mere 128 kB of stack space. That's normally plenty, but apparently ASAN makes things like alloca (or more specifically, C99 vararrays) use quite a bit more than normal. Simply increasing the stack to 1 MB makes the crash in this bug, and ever other open ASAN Opus crash go away.

Patch forthcoming (a non-clobber build takes over 20 minutes on this machine for even a single changed file).
(Assignee)

Comment 21

5 years ago
Created attachment 629534 [details] [diff] [review]
Use larger stacks on the media decoder threads with ASAN

My build still hasn't finished, but I need to run. This _should_ work.
Assignee: giles → tterribe
Status: NEW → ASSIGNED
Attachment #629534 - Flags: review?(kinetik)
Attachment #629534 - Flags: review?(kinetik) → review+
(Reporter)

Comment 22

5 years ago
Fixed. I will mark the other bugs as resolved.
(Assignee)

Comment 23

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/902cd184dca8
Flags: in-testsuite-
Target Milestone: --- → mozilla15
https://hg.mozilla.org/mozilla-central/rev/902cd184dca8
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
(Reporter)

Updated

5 years ago
Status: RESOLVED → VERIFIED
status-firefox-esr10: --- → unaffected
status-firefox15: --- → fixed
status-firefox16: --- → fixed
tracking-firefox15: --- → +
tracking-firefox16: --- → +
Keywords: sec-critical
Group: core-security
You need to log in before you can comment on or make changes to this bug.