994326 - heap-use-after-free in SignalPipeWatcher::OpenFd()

Status: RESOLVED DUPLICATE of bug 990230

(Core :: XPCOM, defect)

Description

[Tyson Smith [:tsmith]]

Attachment: stack_trace.txt

Found by the BlackBerry Security Automated Analysis Team's fuzzing framework ALF.

Unfortunately at this time I do not have a test case for this issue. I will attach one as soon as one is available.

==6417==ERROR: AddressSanitizer: heap-use-after-free on address 0x6030004441c8 at pc 0x7f0bbca95f85 bp 0x7f0bb0a0e5b0 sp 0x7f0bb0a0e5a8
READ of size 1 at 0x6030004441c8 thread T4 (Gecko_IOThread)
    #0 0x7f0bbca95f84 (libxul.so!SignalPipeWatcher::OpenFd()+0x3f4)
    Line 152 of "/builds/slave/m-cen-l64-asan-000000000000000/build/xpcom/base/nsDumpUtils.cpp"
    #1 0x7f0bbca94b60 (libxul.so!FdWatcher::StartWatching()+0x40)
    Line 83 of "/builds/slave/m-cen-l64-asan-000000000000000/build/xpcom/base/nsDumpUtils.cpp"
    #2 0x7f0bbd2e3914 (libxul.so!MessageLoop::DeferOrRunPendingTask(MessageLoop::PendingTask const&)+0x244)
    Line 344 of "/builds/slave/m-cen-l64-asan-000000000000000/build/ipc/chromium/src/base/message_loop.cc"
    #3 0x7f0bbd2e49c7 (libxul.so!MessageLoop::DoWork()+0x447)
    Line 430 of "/builds/slave/m-cen-l64-asan-000000000000000/build/ipc/chromium/src/base/message_loop.cc"
    #4 0x7f0bbd2b5dfc (libxul.so!base::MessagePumpLibevent::Run(base::MessagePump::Delegate*)+0x3cc)
    Line 311 of "/builds/slave/m-cen-l64-asan-000000000000000/build/ipc/chromium/src/base/message_pump_libevent.cc"
...
Full log attached.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

Something to do with memory reporter? Wasn't there a similar bug lately?

Comment 2

[Andrew McCreight [:mccr8]]

Nathan, does this look familiar?

Comment 3

[Nathan Froyd [:froydnj]]

(In reply to Andrew McCreight [:mccr8] from comment #2)
> Nathan, does this look familiar?

Nope, doesn't look familiar.  I can believe it, though, we have singletons without any sort of locking occuring, that's bound to end badly.

Comment 4

[Nathan Froyd [:froydnj]]

Wait, though, it looks like we're still in the middle of XPCOM initialization when that second thread tries to start an IPC message loop.  Is that even something we support?

Comment 5

[Dave Hylands [:dhylands]]

I took a quick look at the stack trace and this looks like a dup of bug 990230.

I'm away and will be back on Tuesday. I can take a more detailed look then.