1421758 - Crash near null [@ GetNextSibling]

Status: RESOLVED FIXED

(Core :: DOM: Events, defect)

Description

[Jason Kratzer [:jkratzer]]

Attachment: trigger.html

Testcase found while fuzzing mozilla-central rev 3f6b9aaed8cd.

==4451==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000030 (pc 0x7fb9922497e5 bp 0x7ffd94c149f0 sp 0x7ffd94c14780 T0)
==4451==The signal is caused by a READ memory access.
==4451==Hint: address points to the zero page.
    #0 0x7fb9922497e4 in GetNextSibling /builds/worker/workspace/build/src/dom/base/nsINode.h:1406:47
    #1 0x7fb9922497e4 in GetNextNodeImpl /builds/worker/workspace/build/src/dom/base/nsINode.h:1470
    #2 0x7fb9922497e4 in GetNextNode /builds/worker/workspace/build/src/dom/base/nsINode.h:1418
    #3 0x7fb9922497e4 in IsNextNodeOfLastAddedNode /builds/worker/workspace/build/src/dom/events/IMEContentObserver.cpp:1314
    #4 0x7fb9922497e4 in mozilla::IMEContentObserver::NotifyContentAdded(nsINode*, nsIContent*, nsIContent*) /builds/worker/workspace/build/src/dom/events/IMEContentObserver.cpp:1049
    #5 0x7fb98fe851d1 in nsNodeUtils::ContentAppended(nsIContent*, nsIContent*) /builds/worker/workspace/build/src/dom/base/nsNodeUtils.cpp:167:3
    #6 0x7fb98ec6032f in nsHtml5TreeOperation::Append(nsIContent*, nsIContent*, nsHtml5DocumentBuilder*) /builds/worker/workspace/build/src/parser/html/nsHtml5TreeOperation.cpp:186:5
    #7 0x7fb98ec68df4 in nsHtml5TreeOperation::Perform(nsHtml5TreeOpExecutor*, nsIContent**, bool*, bool*) /builds/worker/workspace/build/src/parser/html/nsHtml5TreeOperation.cpp:828:14
    #8 0x7fb98ec67056 in nsHtml5TreeOpExecutor::RunFlushLoop() /builds/worker/workspace/build/src/parser/html/nsHtml5TreeOpExecutor.cpp:492:29
    #9 0x7fb98ec73dcf in nsHtml5ExecutorReflusher::Run() /builds/worker/workspace/build/src/parser/html/nsHtml5TreeOpExecutor.cpp:56:18
    #10 0x7fb98cbc8b84 in mozilla::SchedulerGroup::Runnable::Run() /builds/worker/workspace/build/src/xpcom/threads/SchedulerGroup.cpp:396:25
    #11 0x7fb98cbef45e in nsThread::ProcessNextEvent(bool, bool*) /builds/worker/workspace/build/src/xpcom/threads/nsThread.cpp:1033:14
    #12 0x7fb98cc0b1e0 in NS_ProcessNextEvent(nsIThread*, bool) /builds/worker/workspace/build/src/xpcom/threads/nsThreadUtils.cpp:508:10
    #13 0x7fb98da7bc3a in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) /builds/worker/workspace/build/src/ipc/glue/MessagePump.cpp:97:21
    #14 0x7fb98d9d2ed9 in RunInternal /builds/worker/workspace/build/src/ipc/chromium/src/base/message_loop.cc:326:10
    #15 0x7fb98d9d2ed9 in RunHandler /builds/worker/workspace/build/src/ipc/chromium/src/base/message_loop.cc:319
    #16 0x7fb98d9d2ed9 in MessageLoop::Run() /builds/worker/workspace/build/src/ipc/chromium/src/base/message_loop.cc:299
    #17 0x7fb993e7896a in nsBaseAppShell::Run() /builds/worker/workspace/build/src/widget/nsBaseAppShell.cpp:157:27
    #18 0x7fb998596edb in XRE_RunAppShell() /builds/worker/workspace/build/src/toolkit/xre/nsEmbedFunctions.cpp:865:22
    #19 0x7fb98d9d2ed9 in RunInternal /builds/worker/workspace/build/src/ipc/chromium/src/base/message_loop.cc:326:10
    #20 0x7fb98d9d2ed9 in RunHandler /builds/worker/workspace/build/src/ipc/chromium/src/base/message_loop.cc:319
    #21 0x7fb98d9d2ed9 in MessageLoop::Run() /builds/worker/workspace/build/src/ipc/chromium/src/base/message_loop.cc:299
    #22 0x7fb9985968cd in XRE_InitChildProcess(int, char**, XREChildData const*) /builds/worker/workspace/build/src/toolkit/xre/nsEmbedFunctions.cpp:691:34
    #23 0x4ee9f5 in content_process_main /builds/worker/workspace/build/src/browser/app/../../ipc/contentproc/plugin-container.cpp:63:30
    #24 0x4ee9f5 in main /builds/worker/workspace/build/src/browser/app/nsBrowserApp.cpp:280
    #25 0x7fb9abac182f in __libc_start_main /build/glibc-bfm8X4/glibc-2.23/csu/../csu/libc-start.c:291

Comment 1

[Hsin-Yi Tsai (she/her) [:hsinyi]]

The test case was using the shadow DOM v0 API, wondering whether this issue would be valid after we remove Shadow DOM v0 code. Or the root cause is somewhere deeper?

Comment 2

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

aha, this needs the fuzzing addon.

Comment 3

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

Seems like the error is in IMEContentObserver

Comment 4

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

Attachment: IME_and_ShadowDOM.diff

At least we need to do this.
If we want to support designMode or contentEditable or such across shadow DOM boundaries, we'll need to do something else. (and get that all spec'ed)
Chrome doesn't seem to support designMode across shadow boundaries.

Comment 5

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

remote: View your change here:
remote:   https://hg.mozilla.org/try/rev/d25c684c20c8c4c98b052b35f8a428b2ec6a5cd3
remote: 
remote: Follow the progress of your build on Treeherder:
remote:   https://treeherder.mozilla.org/#/jobs?repo=try&revision=d25c684c20c8c4c98b052b35f8a428b2ec6a5cd3
remote: recorded changegroup in replication log in 0.052s

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/b38e02c0b605
IME handling shouldn't cross shadow boundaries, r=masayuki

Comment 7

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/b38e02c0b605