Closed Bug 1723946 Opened 2 years ago Closed 1 year ago

IPC Parent Crash [@ __pthread_mutex_cond_lock] through [@ mozilla::net::SocketProcessChild::AddDataBridgeToMap]


(Core :: Networking, defect, P2)




95 Branch
Tracking Status
firefox-esr78 --- wontfix
firefox-esr91 --- wontfix
firefox92 --- wontfix
firefox93 --- wontfix
firefox94 --- wontfix
firefox95 --- fixed


(Reporter: decoder, Assigned: kershaw)


(5 keywords, Whiteboard: [necko-triaged][post-critsmash-triage][adv-main95-])

Crash Data


(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).

Severity: -- → S2
Crash Signature: [@ __pthread_mutex_cond_lock] → [@ __pthread_mutex_cond_lock] [@ mozilla::net::SocketProcessChild::AddDataBridgeToMap]
Keywords: sec-other
Component: IPC → Networking

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.

Flags: needinfo?(kershaw)
Assignee: nobody → kershaw
Severity: S2 → S3
Flags: needinfo?(kershaw)
Priority: -- → P2
Whiteboard: [necko-triaged]
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 95 Branch
Flags: qe-verify-
Whiteboard: [necko-triaged] → [necko-triaged][post-critsmash-triage]
Whiteboard: [necko-triaged][post-critsmash-triage] → [necko-triaged][post-critsmash-triage][adv-main95-]
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.