858318 - WebVTT heap-buffer-overflow [@mozilla::dom::FragmentOrElement::CanSkipThis]

Status: RESOLVED WORKSFORME

(Core :: Audio/Video, defect)

Description

[Raymond Forbes[:rforbes]]

==50217==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x601a00266b98 at pc 0x103f32159 bp 0x113d3eaa0 sp 0x113d3ea98
READ of size 8 at 0x601a00266b98 thread T5
    #0 0x103f32158 in nsINodeInfo::GetDocument const nsINodeInfo.h:280
    #1 0x1048e5ec3 in mozilla::dom::FragmentOrElement::CanSkipThis FragmentOrElement.cpp:1554
    #2 0x1048e5f70 in mozilla::dom::FragmentOrElement::cycleCollection::CanSkipThisImpl FragmentOrElement.cpp:1576
    #3 0x106caff0d in nsCycleCollectionParticipant::CanSkipThis nsCycleCollectionParticipant.h:225
    #4 0x106caaa04 in GCGraphBuilder::NoteXPCOMChild nsCycleCollector.cpp:1730
    #5 0x1048e6439 in mozilla::dom::FragmentOrElement::cycleCollection::TraverseImpl FragmentOrElement.cpp:1676
    #6 0x104c3c91f in mozilla::dom::HTMLMediaElement::cycleCollection::TraverseImpl HTMLMediaElement.cpp:403
    #7 0x106caa0ed in GCGraphBuilder::Traverse nsCycleCollector.cpp:1645
    #8 0x106cabbc1 in nsCycleCollector::MarkRoots nsCycleCollector.cpp:1947
    #9 0x106cae543 in nsCycleCollector::BeginCollection nsCycleCollector.cpp:2525
    #10 0x106cb673f in nsCycleCollectorRunner::Run nsCycleCollector.cpp:2709
    #11 0x106c8515b in nsThread::ProcessNextEvent nsThread.cpp:627
    #12 0x106bc3958 in NS_ProcessNextEvent_P nsThreadUtils.cpp:238
    #13 0x106c8336c in nsThread::ThreadFunc nsThread.cpp:265
    #14 0x10327d3fb in _pt_root (in libnss3.dylib) + 715
    #15 0x100028f1a in __asan::AsanThread::ThreadStart() (in libclang_rt.asan_osx_dynamic.dylib) + 42
    #16 0x7fff92c56180 in thread_start (in libsystem_c.dylib) + 12
0x601a00266b98 is located 8 bytes inside of 136-byte region [0x601a00266b90,0x601a00266c18)
freed by thread T0 here:
    #0 0x100023018 in wrap_free (in libclang_rt.asan_osx_dynamic.dylib) + 56
    #1 0x10484463b in nsNodeInfo::LastRelease nsNodeInfo.cpp:203
    #2 0x104844294 in nsNodeInfo::Release nsNodeInfo.cpp:165
    #3 0x106bc44a0 in nsXPCOMCycleCollectionParticipant::UnrootImpl nsCycleCollectionParticipant.cpp:37
    #4 0x106cacaf9 in nsCycleCollector::CollectWhite nsCycleCollector.cpp:2157
    #5 0x106cae7de in nsCycleCollector::FinishCollection nsCycleCollector.cpp:2558
    #6 0x106cb0fc9 in nsCycleCollectorRunner::Collect nsCycleCollector.cpp:2772
    #7 0x106caf1cb in nsCycleCollector_collect nsCycleCollector.cpp:2861
    #8 0x104e34bcd in nsJSContext::CycleCollectNow nsJSEnvironment.cpp:2779
    #9 0x104e41fd4 in CCTimerFired nsJSEnvironment.cpp:2990
    #10 0x106c91dca in nsTimerImpl::Fire nsTimerImpl.cpp:543
    #11 0x106c9254d in nsTimerEvent::Run nsTimerImpl.cpp:630
    #12 0x106c8515b in nsThread::ProcessNextEvent nsThread.cpp:627
    #13 0x106bc375e in NS_ProcessPendingEvents_P nsThreadUtils.cpp:188
    #14 0x106108ed3 in nsBaseAppShell::NativeEventCallback nsBaseAppShell.cpp:97
    #15 0x10608009d in nsAppShell::ProcessGeckoEvents nsAppShell.mm:387
    #16 0x7fff90dea100 in __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ (in CoreFoundation) + 16
    #17 0x7fff90de9a24 in __CFRunLoopDoSources0 (in CoreFoundation) + 244
    #18 0x7fff90e0cdc4 in __CFRunLoopRun (in CoreFoundation) + 788
    #19 0x7fff90e0c6b1 in CFRunLoopRunSpecific (in CoreFoundation) + 289
    #20 0x7fff9711e0a3 in RunCurrentEventLoopInMode (in HIToolbox) + 208
    #21 0x7fff9711de41 in ReceiveNextEventCommon (in HIToolbox) + 355
    #22 0x7fff9711dcd2 in BlockUntilNextEventMatchingListInMode (in HIToolbox) + 61
    #23 0x7fff8f93d612 in _DPSNextEvent (in AppKit) + 684
    #24 0x7fff8f93ced1 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] (in AppKit) + 127
    #25 0x10607e78b in -[GeckoNSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] nsAppShell.mm:164
    #26 0x7fff8f934282 in -[NSApplication run] (in AppKit) + 516
    #27 0x106080c65 in nsAppShell::Run nsAppShell.mm:741
    #28 0x105c22c9d in nsAppStartup::Run nsAppStartup.cpp:288
    #29 0x10388d5b3 in XREMain::XRE_mainRun nsAppRunner.cpp:3880
previously allocated by thread T0 here:
    #0 0x100022f93 in wrap_malloc (in libclang_rt.asan_osx_dynamic.dylib) + 51
    #1 0x103876257 in moz_xmalloc mozalloc.cpp:54
    #2 0x104845f6e in nsNodeInfoManager::GetNodeInfo mozalloc.h:201
    #3 0x1052c7fdd in nsHtml5TreeOperation::Perform nsHtml5TreeOperation.cpp:341
    #4 0x1052d0de4 in nsHtml5TreeOpExecutor::RunFlushLoop nsHtml5TreeOpExecutor.cpp:557
    #5 0x1052e19c4 in nsHtml5ExecutorFlusher::Run nsHtml5StreamParser.cpp:125
    #6 0x106c8515b in nsThread::ProcessNextEvent nsThread.cpp:627
    #7 0x106bc375e in NS_ProcessPendingEvents_P nsThreadUtils.cpp:188
    #8 0x106108ed3 in nsBaseAppShell::NativeEventCallback nsBaseAppShell.cpp:97
    #9 0x10608009d in nsAppShell::ProcessGeckoEvents nsAppShell.mm:387
    #10 0x7fff90dea100 in __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ (in CoreFoundation) + 16
    #11 0x7fff90de9a24 in __CFRunLoopDoSources0 (in CoreFoundation) + 244
    #12 0x7fff90e0cdc4 in __CFRunLoopRun (in CoreFoundation) + 788
    #13 0x7fff90e0c6b1 in CFRunLoopRunSpecific (in CoreFoundation) + 289
    #14 0x7fff9711e0a3 in RunCurrentEventLoopInMode (in HIToolbox) + 208
    #15 0x7fff9711de41 in ReceiveNextEventCommon (in HIToolbox) + 355
    #16 0x7fff9711dcd2 in BlockUntilNextEventMatchingListInMode (in HIToolbox) + 61
    #17 0x7fff8f93d612 in _DPSNextEvent (in AppKit) + 684
    #18 0x7fff8f93ced1 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] (in AppKit) + 127
    #19 0x10607e78b in -[GeckoNSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] nsAppShell.mm:164
    #20 0x7fff8f934282 in -[NSApplication run] (in AppKit) + 516
    #21 0x106080c65 in nsAppShell::Run nsAppShell.mm:741
    #22 0x105c22c9d in nsAppStartup::Run nsAppStartup.cpp:288
    #23 0x10388d5b3 in XREMain::XRE_mainRun nsAppRunner.cpp:3880
    #24 0x10388e6ea in XREMain::XRE_main nsAppRunner.cpp:3947
    #25 0x10388ec69 in XRE_main nsAppRunner.cpp:4150
    #26 0x1000027c3 in 0x2000027c3
    #27 0x100001a38 in 0x200001a38
    #28 0x100000fc3 in 0x200000fc3
    #29 0x4 in 0x0000000100000004 (in firefox)
Thread T5 created by T0 here:
    #0 0x10001e534 in wrap_pthread_create (in libclang_rt.asan_osx_dynamic.dylib) + 36
    #1 0x103278ea9 in _PR_CreateThread (in libnss3.dylib) + 1593
    #2 0x10327885a in PR_CreateThread (in libnss3.dylib) + 26
    #3 0x106c83dd7 in nsThread::Init nsThread.cpp:331
    #4 0x106c88b25 in nsThreadManager::NewThread nsThreadManager.cpp:215
    #5 0x106bc30d3 in NS_NewThread_P nsThreadUtils.cpp:67
    #6 0x106caed61 in nsCycleCollector_startup nsCycleCollector.cpp:2812
    #7 0x106bd461f in NS_InitXPCOM2_P nsXPComInit.cpp:443
    #8 0x10388387f in ScopedXPCOMStartup::Initialize nsAppRunner.cpp:1182
    #9 0x10388e6d1 in XREMain::XRE_main nsAppRunner.cpp:3943
    #10 0x10388ec69 in XRE_main nsAppRunner.cpp:4150
    #11 0x1000027c3 in 0x2000027c3
    #12 0x100001a38 in 0x200001a38
    #13 0x100000fc3 in 0x200000fc3
    #14 0x4 in 0x0000000100000004 (in firefox)
Shadow bytes around the buggy address:
  0x1c034004cd20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c034004cd30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa 00 00
  0x1c034004cd40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fa
  0x1c034004cd50: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
  0x1c034004cd60: 00 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa
=>0x1c034004cd70: fa fa fa[fa]fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c034004cd80: fa fa fa fa fa fa fa fa fa fa fa fa 00 00 00 00
  0x1c034004cd90: 00 00 00 00 00 00 00 00 00 00 00 00 00 fa fa fa
  0x1c034004cda0: fa fa fa fa fa fa 00 00 00 00 00 00 00 00 00 00
  0x1c034004cdb0: 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa fa
  0x1c034004cdc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:     fa
  Heap righ redzone:     fb
  Freed Heap region:     fd
  Stack left redzone:    f1
  Stack mid redzone:     f2
  Stack right redzone:   f3
  Stack partial redzone: f4
  Stack after return:    f5
  Stack use after scope: f8
  Global redzone:        f9
  Global init order:     f6
  Poisoned by user:      f7
  ASan internal:         fe
==50217==ABORTING

Comment 1

[Raymond Forbes[:rforbes]]

Attachment: testcase

Comment 2

[Raymond Forbes[:rforbes]]

Attachment: stacktrace

Comment 3

[Mats Palmgren (inactive)]

It looks like nsCycleCollectorRunner is running on a non-main thread in the
attached stack trace.  Is that supposed to happen?

Comment 4

[Andrew McCreight [:mccr8]]

Yes, the cycle collector is run on a separate thread while the main thread is paused, in some kind of attempt to preserve the cache.

Comment 5

[Andrew McCreight [:mccr8]]

The stack trace is fairly odd.  The cycle collector runner is running on the main thread, where it causes a last release on an nsNodeInfo.  Then later the cycle collector runs off the main thread, and then tries to touch the same node info.

a) why is the runner running on the main thread?
b) why has refcounting failed here?  The media element appears to have a CC-child that is a node that is holding onto a node info that was freed due to having 0 refcount...

I'd be inclined to blame bug 839025, but the line numbers don't seem to match up.  rforbes, does the version you ran this on include bug 839025?

Comment 6

[Andrew McCreight [:mccr8]]

Though, I guess because this is a heap buffer overflow, maybe it isn't a UAF.  I'm still not sure how that would happen...

Comment 7

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

The line numbers definitely look like a pre-bug 839025 build.

Comment 8

[Raymond Forbes[:rforbes]]

i have a bunch of bugs similar to this.  should i update and redo my fuzzing before i submit them?

Comment 9

[Andrew McCreight [:mccr8]]

No, that other patch shouldn't change the behavior.

Comment 10

[Andrew McCreight [:mccr8]]

rforbes, is this against a tree with bug 833385?  Does it still reproduce?  The patch there has been updated a few times since this was posted, to fix some UAF errors that were found by inspection by Ms2ger.

Comment 11

[Andrew McCreight [:mccr8]]

I'm going to assume from the test case, which involves track, that this is a regression against bug 833385, which hasn't landed yet.  rillian, you should make sure these are all fixed before landing.  Let me know if you'd like some help figuring them out.

Comment 12

[Raymond Forbes[:rforbes]]

this was from rillian's branch that has the webvtt support.  i have updated and re-ran the fuzzer and so far haven't hit this one again so i am guessing it is either fixed or was a false positive.

Comment 13

[Christoph Diehl [:posidron]]

In ASan, false positives (stack unwinding) are marked as such in the ASan trace, that is not the case here. It looks more like the crash is either intermittent (GarbageCollector ?) or fixed.

Comment 14

[Ralph Giles (:rillian)]

(In reply to Christoph Diehl [:cdiehl] from comment #13)
> It looks more like the crash is either
> intermittent (GarbageCollector ?) or fixed.

That's what I'd like to know, and since I haven't been able to reproduce the original I can't bisect. Do we have a policy for 'upstream seems to have fixed'?

Comment 15

[Christoph Diehl [:posidron]]

This is not reproducible anymore. It involved the old WebVTT parser which is not anymore in our code base.