1521832 - Crash in arena_t::DallocSmall | mozilla::net::nsSocketEvent::Run

Status: RESOLVED DUPLICATE of bug 1516325

(Core :: Networking, defect)

Description

[Asif Youssuff]

This bug is for crash report bp-426e4d0e-c517-47b1-bc21-5eed90190122.

Top 10 frames of crashing thread:

0  @0x2107778e62 
1 libmozglue.dylib arena_t::DallocSmall memory/build/rb.h:142
2  @0x10a7e3809 
3 XUL mozilla::net::nsSocketEvent::Run netwerk/base/nsSocketTransport2.cpp
4 libmozglue.dylib arena_t::DallocSmall memory/build/mozjemalloc.cpp:3444
5 libmozglue.dylib BaseAllocator::free memory/build/mozjemalloc.cpp:3532
6 libmozglue.dylib free memory/build/malloc_decls.h:40
7 XUL mozilla::Runnable::Release xpcom/threads/nsThreadUtils.cpp:47
8 XUL nsThread::ProcessNextEvent xpcom/base/nsCOMPtr.h:371
9 libmozglue.dylib mozilla::detail::MutexImpl::lock mozglue/misc/Mutex_posix.cpp:132

User reports that they get the crash when browsing Twitter or YouTube: https://twitter.com/daslaf/status/1087528942163120130

Comment 1

[Andrew Overholt [:overholt]]

Possible dupe of bug 1516325?

Comment 2

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

A guess: this is a variant of bug 1516325 where the corrupt address is still canonical (a sign-extended 48-bit value), so the ret instruction sets rip and then the next instruction fetch causes a page fault; the other one is when it's non-canonical so the ret itself takes a general protection fault.

In particular, the rip in bp-426e4d0e-c517-47b1-bc21-5eed90190122 is 0x2000000000 plus what would be a valid address in libnss3.dylib, and the reported fault address is the bottom 32 bits of the same value, which makes sense if there's an out-of-bounds write to a bit set on the stack.