sandbox causes crash when attempting Vorbis decoding on RDD

RESOLVED FIXED in Firefox 68

Status

()

defect
P1
normal
RESOLVED FIXED
2 months ago
2 months ago

People

(Reporter: mjf, Assigned: jld)

Tracking

unspecified
mozilla68
Points:
---

Firefox Tracking Flags

(firefox68 fixed)

Details

(crash signature)

Attachments

(2 attachments)

Reporter

Description

2 months ago

While trying to verify behavior I was seeing on macOS, I tried turning on Vorbis decoding on RDD on linux. On RDD initializing the Vorbis decoder causes an sandbox exception:

1:19.46 GECKO(11475) Sandbox: seccomp sandbox violation: pid 11698, tid 11705, syscall 99, args 139971286315296 2048 139971796575892 88 0 12335137464869716225. Killing
process.
1:19.46 GECKO(11475) Sandbox: crash reporter is disabled (or failed); trying stack trace:
1:19.52 GECKO(11475) Sandbox: frame #01: __restore_rt (sigaction.c:?)
1:21.93 GECKO(11475) Sandbox: frame #02: __sysinfo (/build/glibc-OTsEL5/glibc-2.27/misc/../sysdeps/unix/syscall-template.S:78)
1:21.93 GECKO(11475) Sandbox: frame #03: __GI___get_phys_pages (/build/glibc-OTsEL5/glibc-2.27/misc/../sysdeps/unix/sysv/linux/getsysstats.c:323)
1:21.93 GECKO(11475) Sandbox: frame #04: posix_sysconf (/build/glibc-OTsEL5/glibc-2.27/posix/../sysdeps/posix/sysconf.c:634)
1:21.93 GECKO(11475) Sandbox: frame #05: __GI___qsort_r (/build/glibc-OTsEL5/glibc-2.27/stdlib/msort.c:189)
readelf: Warning: Bogus end-of-siblings marker detected at offset 11f72e9a in .debug_info section
readelf: Warning: Bogus end-of-siblings marker detected at offset 11f72e9b in .debug_info section
readelf: Warning: Bogus end-of-siblings marker detected at offset 11f72e9c in .debug_info section
readelf: Warning: Further warnings about bogus end-of-sibling markers suppressed
readelf: Warning: Bogus end-of-siblings marker detected at offset 11f72e9a in .debug_info section
readelf: Warning: Bogus end-of-siblings marker detected at offset 11f72e9b in .debug_info section
readelf: Warning: Bogus end-of-siblings marker detected at offset 11f72e9c in .debug_info section
readelf: Warning: Further warnings about bogus end-of-sibling markers suppressed
1:39.87 GECKO(11475) Sandbox: frame #06: vorbis_book_init_decode (/home/mfroman/mozilla/moz-central/media/libvorbis/lib/vorbis_sharedbook.c:358)
1:39.88 GECKO(11475) Sandbox: frame #07: _vds_shared_init (/home/mfroman/mozilla/moz-central/media/libvorbis/lib/vorbis_block.c:240)
1:39.89 GECKO(11475) Sandbox: frame #08: vorbis_synthesis_init (/home/mfroman/mozilla/moz-central/media/libvorbis/lib/vorbis_block.c:709)
1:39.97 GECKO(11475) Sandbox: frame #09: mozilla::VorbisDataDecoder::Init() (/home/mfroman/mozilla/moz-central/dom/media/platforms/agnostic/VorbisDecoder.cpp:87)
1:39.98 GECKO(11475) Sandbox: frame #10: mozilla::RemoteDecoderParent::RecvInit() (/home/mfroman/mozilla/moz-central/dom/media/ipc/RemoteDecoderParent.cpp:44)
1:40.01 GECKO(11475) Sandbox: frame #11: mozilla::PRemoteDecoderParent::OnMessageReceived(IPC::Message const&) (/home/mfroman/mozilla/obj/deb/ipc/ipdl/PRemoteDecoderParent.cpp:223)
1:40.02 GECKO(11475) Sandbox: frame #12: mozilla::PRemoteDecoderManagerParent::OnMessageReceived(IPC::Message const&) (/home/mfroman/mozilla/obj/deb/ipc/ipdl/PRemoteDecoderManagerParent.cpp:137)
1:40.06 GECKO(11475) Sandbox: frame #13: mozilla::ipc::MessageChannel::DispatchAsyncMessage(IPC::Message const&) (/home/mfroman/mozilla/moz-central/ipc/glue/MessageChannel.cpp:2151)
1:41.58 GECKO(11475) Sandbox: frame #14: mozilla::ipc::MessageChannel::DispatchMessage(IPC::Message&&) (Unified_cpp_ipc_glue1.cpp:?)
1:41.61 GECKO(11475) Sandbox: frame #15: mozilla::ipc::MessageChannel::RunMessage(mozilla::ipc::MessageChannel::MessageTask&) (Unified_cpp_ipc_glue1.cpp:?)
1:41.62 GECKO(11475) Sandbox: frame #16: mozilla::ipc::MessageChannel::MessageTask::Run() (/home/mfroman/mozilla/moz-central/ipc/glue/MessageChannel.cpp:1969)
1:41.66 GECKO(11475) Sandbox: frame #17: nsThread::ProcessNextEvent(bool, bool*) (/home/mfroman/mozilla/moz-central/xpcom/threads/nsThread.cpp:1182)
1:41.67 GECKO(11475) Sandbox: frame #18: NS_ProcessNextEvent(nsIThread*, bool) (/home/mfroman/mozilla/moz-central/xpcom/threads/nsThreadUtils.cpp:486)
1:41.68 GECKO(11475) Sandbox: frame #19: mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) (/home/mfroman/mozilla/moz-central/ipc/glue/MessagePump.cpp:334)
1:41.70 GECKO(11475) Sandbox: frame #20: MessageLoop::RunInternal() (/home/mfroman/mozilla/moz-central/ipc/chromium/src/base/message_loop.cc:315)
1:41.72 GECKO(11475) Sandbox: frame #21: MessageLoop::RunHandler() (/home/mfroman/mozilla/moz-central/ipc/chromium/src/base/message_loop.cc:309)
1:41.73 GECKO(11475) Sandbox: frame #22: MessageLoop::Run() (/home/mfroman/mozilla/moz-central/ipc/chromium/src/base/message_loop.cc:290)
1:41.74 GECKO(11475) Sandbox: frame #23: nsThread::ThreadFunc(void*) (/home/mfroman/mozilla/moz-central/xpcom/threads/nsThread.cpp:456)
1:41.81 GECKO(11475) Sandbox: frame #24: _pt_root (/home/mfroman/mozilla/moz-central/nsprpub/pr/src/pthreads/ptthread.c:204)
1:41.81 GECKO(11475) Sandbox: frame #25: start_thread (/build/glibc-OTsEL5/glibc-2.27/nptl/pthread_create.c:463)
1:41.81 GECKO(11475) Sandbox: frame #26: __GI___clone (/build/glibc-OTsEL5/glibc-2.27/misc/../sysdeps/unix/sysv/linux/x86_64/clone.S:97)
1:41.81 GECKO(11475) Sandbox: frame #27: ??? (???:???)
1:41.81 GECKO(11475) Sandbox: end of stack.

I'll include the patch needed to enable vorbis on linux (on everything really, just for this test) and to trim a mochitest down to a reasonably quick test case.

The only time I see the full stack of from the sandbox is running under rr like this:
./mach mochitest --debugger=rr --keep-open=false dom/media/test/test_playback.html

If I run outside of rr, I only see the first line from above:
1:19.46 GECKO(11475) Sandbox: seccomp sandbox violation: pid 11698, tid 11705, syscall 99, args 139971286315296 2048 139971796575892 88 0 12335137464869716225. Killing
process.

Reporter

Comment 1

2 months ago

Jed, any thoughts here?

Flags: needinfo?(jld)

glibc's qsort calls sysconf to find out how much RAM there is in case the input is big enough that it matters. For libvorbis' tables it's probably not an issue, but it does it anyway. For _SC_PHYS_PAGES, this uses the sysinfo system call.

It should be enough to add case __NR_sysinfo: return Error(EPERM); to SandboxPolicyCommon::EvaluateSyscall; qsort falls back to assuming there's adequate RAM.

As for the stack trace, does setting the MOZ_CRASHREPORTER_DISABLE environment variable help?

Assignee: nobody → jld
Flags: needinfo?(jld)
Priority: -- → P1
Reporter

Comment 3

2 months ago

(In reply to Jed Davis [:jld] ⟨⏰|UTC-6⟩ ⟦he/him⟧ from comment #2)

As for the stack trace, does setting the MOZ_CRASHREPORTER_DISABLE environment variable help?

Setting MOZ_CRASHREPORTER_DISABLE doesn't seem to have any effect on getting the full sandbox stack trace when not in rr.

(In reply to Michael Froman [:mjf] from comment #3)

(In reply to Jed Davis [:jld] ⟨⏰|UTC-6⟩ ⟦he/him⟧ from comment #2)

As for the stack trace, does setting the MOZ_CRASHREPORTER_DISABLE environment variable help?

Setting MOZ_CRASHREPORTER_DISABLE doesn't seem to have any effect on getting the full sandbox stack trace when not in rr.

But it is writing a minidump, and if I set things up correctly (set $MINIDUMP_STACKWALK to the path to minidump_stackwalk from my local build of Breakpad and run ./mach buildsymbols first) then ./mach test will unwind it… except that it doesn't show anything inside libc (and in theory it's affected by bug 1310314, but qsort_r has a frame pointer because it uses alloca).

It looks like the way the sandbox hooks into the crash reporter isn't affected by the crash reporter's normal runtime enabling/disabling, and I don't know if it ever has. (It was originally written for B2G where that wasn't as much of an issue, and hasn't been looked at much in the meantime.) I'll file a bug.

I have a patch and the test is failing with failed | spacestorm-1000Hz-100ms.ogg duration (0.256) should be around 0.099 now, but no other sandbox problems.

Reporter

Comment 7

2 months ago

(In reply to Jed Davis [:jld] ⟨⏰|UTC-6⟩ ⟦he/him⟧ from comment #5)

I have a patch and the test is failing with failed | spacestorm-1000Hz-100ms.ogg duration (0.256) should be around 0.099 now, but no other sandbox problems.

Excellent, thank you! That is the failure that led me to try things on linux to begin with, so expected to some degree.

Comment 8

2 months ago
Pushed by jedavis@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/01d9700306a4
Adjust Linux sandbox policies to tolerate glibc's qsort. r=gcp

Comment 9

2 months ago
bugherder
Status: NEW → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68
Duplicate of this bug: 1547768
Crash Signature: [@ libc-2.28.so@0xfa497]
You need to log in before you can comment on or make changes to this bug.