IPC Parent Crash [@ __pthread_mutex_cond_lock] through [@ mozilla::net::SocketProcessChild::AddDataBridgeToMap]
Categories
(Core :: Networking, defect, P2)
Tracking
()
People
(Reporter: decoder, Assigned: kershaw)
Details
(5 keywords, Whiteboard: [necko-triaged][post-critsmash-triage][adv-main95-])
Crash Data
Attachments
(2 files)
In experimental IPC fuzzing, we found the following crash on mozilla-central revision 160071ad9de0+ (--enable-address-sanitizer --enable-optimize --enable-fuzzing --disable-debug build):
==1687==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000380 (pc 0x7ffff7d6bfc4 bp 0x7fffc50ea390 sp 0x7fffc50ea378 T26)
==1687==The signal is caused by a READ memory access.
==1687==Hint: address points to the zero page.
#0 0x7ffff7d6bfc4 in __pthread_mutex_cond_lock nptl/pthread_mutex_lock.c:81:0
#1 0x5555557966ca in mozilla::detail::MutexImpl::mutexLock() mozglue/misc/Mutex_posix.cpp:96:3
#2 0x5555557966ca in mozilla::detail::MutexImpl::lock() mozglue/misc/Mutex_posix.cpp:118:43
#3 0x7fffdc58897e in mozilla::OffTheBooksMutex::Lock() objdir/dist/include/mozilla/Mutex.h:63:23
#4 0x7fffdc58897e in mozilla::detail::BaseAutoLock<mozilla::Mutex&>::BaseAutoLock(mozilla::Mutex&) objdir/dist/include/mozilla/Mutex.h:158:57
#5 0x7fffdc58897e in mozilla::net::SocketProcessChild::AddDataBridgeToMap(unsigned long, mozilla::net::BackgroundDataBridgeParent*) netwerk/ipc/SocketProcessChild.cpp:434:17
#6 0x7fffdc8a4a91 in mozilla::ipc::BackgroundParentImpl::AllocPBackgroundDataBridgeParent(unsigned long const&) ipc/glue/BackgroundParentImpl.cpp:154:11
#7 0x7fffde2ab56d in mozilla::ipc::PBackgroundParent::OnMessageReceived(IPC::Message const&) objdir/ipc/ipdl/PBackgroundParent.cpp:3575:65
#8 0x7fffdc94412c in mozilla::ipc::MessageChannel::DispatchAsyncMessage(mozilla::ipc::ActorLifecycleProxy*, IPC::Message const&) ipc/glue/MessageChannel.cpp:2096:25
#9 0x7fffdc94004d in mozilla::ipc::MessageChannel::DispatchMessage(IPC::Message&&) ipc/glue/MessageChannel.cpp:2020:9
#10 0x7fffdc942589 in mozilla::ipc::MessageChannel::RunMessage(mozilla::ipc::MessageChannel::MessageTask&) ipc/glue/MessageChannel.cpp:1861:3
#11 0x7fffdc94303c in mozilla::ipc::MessageChannel::MessageTask::Run() ipc/glue/MessageChannel.cpp:1896:13
We don't have a testcase for this issue (due to the experimental nature of the fuzzer), but it looks like we can simply call the PBackgroundDataBridgeConstructor
with the SocketProcessChild
singleton being nullptr
here:
Not a security problem but we should fix all plain crashes seen in fuzzing (the simplest fix from a fuzzing perspective is to use a MOZ_RELEASE_ASSERT
as these will be ignored), but maybe we also want to handle this differently.
Not a security bug, but marking s-s because we currently don't want to disclose our efforts around IPC fuzzing (until we have it in production).
Reporter | ||
Comment 1•2 years ago
|
||
Reporter | ||
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Comment 2•1 year ago
|
||
We might also have a data race to the sSocketProcessChild pointer here.
Feel free to bounce back to me or another necko member if you have too much on your plate.
Assignee | ||
Comment 3•1 year ago
|
||
Updated•1 year ago
|
Assignee | ||
Updated•1 year ago
|
![]() |
||
Comment 4•1 year ago
|
||
Avoid racing on sSocketProcessChild, r=necko-reviewers,valentin
https://hg.mozilla.org/integration/autoland/rev/b35bcedf83d8810c48696c6856c8987bf64988ca
https://hg.mozilla.org/mozilla-central/rev/b35bcedf83d8
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•6 months ago
|
Description
•