1609775 - AddressSanitizer: SEGV /builds/worker/workspace/build/src/ipc/glue/MessageLink.cpp:151:5 in mozilla::ipc::ProcessLink::SendMessage(IPC::Message*)

Status: NEW

(Core :: DOM: Workers, defect, P3)

Description

[Jason Kratzer [:jkratzer]]

Attachment: testcase.html

Testcase found while fuzzing mozilla-central rev 7e0886a94d70. Testcase must be served via a local webserver in order to reproduce.

==19572==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000001 (pc 0x7f46f3b99aee bp 0x7ffcf4c534d0 sp 0x7ffcf4c533e0 T0)
==19572==The signal is caused by a WRITE memory access.
==19572==Hint: address points to the zero page.
    #0 0x7f46f3b99aed in mozilla::ipc::ProcessLink::SendMessage(IPC::Message*) /builds/worker/workspace/build/src/ipc/glue/MessageLink.cpp:151:5
    #1 0x7f46f3b7ca6f in mozilla::ipc::MessageChannel::SendMessageToLink(IPC::Message*) /builds/worker/workspace/build/src/ipc/glue/MessageChannel.cpp:1031:10
    #2 0x7f46f3b7b026 in mozilla::ipc::MessageChannel::Send(IPC::Message*) /builds/worker/workspace/build/src/ipc/glue/MessageChannel.cpp:1021:3
    #3 0x7f46f3ba868e in mozilla::ipc::IProtocol::ChannelSend(IPC::Message*) /builds/worker/workspace/build/src/ipc/glue/ProtocolUtils.cpp:477:22
    #4 0x7f46f43e1963 in mozilla::dom::PMessagePortChild::SendPostMessages(nsTArray<mozilla::dom::ClonedMessageData> const&) /builds/worker/workspace/build/src/obj-firefox/ipc/ipdl/PMessagePortChild.cpp:73:21
    #5 0x7f46fa509cf0 in mozilla::dom::MessagePort::Entangled(nsTArray<mozilla::dom::ClonedMessageData>&) /builds/worker/workspace/build/src/dom/messagechannel/MessagePort.cpp:570:15
    #6 0x7f46fa50b614 in mozilla::dom::MessagePortChild::RecvEntangled(nsTArray<mozilla::dom::ClonedMessageData>&&) /builds/worker/workspace/build/src/dom/messagechannel/MessagePortChild.cpp:27:12
    #7 0x7f46f43e2e27 in mozilla::dom::PMessagePortChild::OnMessageReceived(IPC::Message const&) /builds/worker/workspace/build/src/obj-firefox/ipc/ipdl/PMessagePortChild.cpp:190:60
    #8 0x7f46f431aedf in mozilla::ipc::PBackgroundChild::OnMessageReceived(IPC::Message const&) /builds/worker/workspace/build/src/obj-firefox/ipc/ipdl/PBackgroundChild.cpp:5876:32
    #9 0x7f46f3b90ac2 in mozilla::ipc::MessageChannel::DispatchAsyncMessage(mozilla::ipc::ActorLifecycleProxy*, IPC::Message const&) /builds/worker/workspace/build/src/ipc/glue/MessageChannel.cpp:2212:25
    #10 0x7f46f3b8b724 in mozilla::ipc::MessageChannel::DispatchMessage(IPC::Message&&) /builds/worker/workspace/build/src/ipc/glue/MessageChannel.cpp:2134:9
    #11 0x7f46f3b8d9ef in mozilla::ipc::MessageChannel::RunMessage(mozilla::ipc::MessageChannel::MessageTask&) /builds/worker/workspace/build/src/ipc/glue/MessageChannel.cpp:1973:3
    #12 0x7f46f3b8e8f0 in mozilla::ipc::MessageChannel::MessageTask::Run() /builds/worker/workspace/build/src/ipc/glue/MessageChannel.cpp:2004:13
    #13 0x7f46f2953c88 in nsThread::ProcessNextEvent(bool, bool*) /builds/worker/workspace/build/src/xpcom/threads/nsThread.cpp:1220:14
    #14 0x7f46f295ea9c in NS_ProcessNextEvent(nsIThread*, bool) /builds/worker/workspace/build/src/xpcom/threads/nsThreadUtils.cpp:486:10
    #15 0x7f46f3b9c44f in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) /builds/worker/workspace/build/src/ipc/glue/MessagePump.cpp:87:21
    #16 0x7f46f3a95ce7 in RunInternal /builds/worker/workspace/build/src/ipc/chromium/src/base/message_loop.cc:315:10
    #17 0x7f46f3a95ce7 in RunHandler /builds/worker/workspace/build/src/ipc/chromium/src/base/message_loop.cc:308:3
    #18 0x7f46f3a95ce7 in MessageLoop::Run() /builds/worker/workspace/build/src/ipc/chromium/src/base/message_loop.cc:290:3
    #19 0x7f46fab3b458 in nsBaseAppShell::Run() /builds/worker/workspace/build/src/widget/nsBaseAppShell.cpp:137:27
    #20 0x7f46fe65d476 in XRE_RunAppShell() /builds/worker/workspace/build/src/toolkit/xre/nsEmbedFunctions.cpp:945:20
    #21 0x7f46f3a95ce7 in RunInternal /builds/worker/workspace/build/src/ipc/chromium/src/base/message_loop.cc:315:10
    #22 0x7f46f3a95ce7 in RunHandler /builds/worker/workspace/build/src/ipc/chromium/src/base/message_loop.cc:308:3
    #23 0x7f46f3a95ce7 in MessageLoop::Run() /builds/worker/workspace/build/src/ipc/chromium/src/base/message_loop.cc:290:3
    #24 0x7f46fe65cb1f in XRE_InitChildProcess(int, char**, XREChildData const*) /builds/worker/workspace/build/src/toolkit/xre/nsEmbedFunctions.cpp:780:34
    #25 0x5636924db3f1 in content_process_main /builds/worker/workspace/build/src/browser/app/../../ipc/contentproc/plugin-container.cpp:56:28
    #26 0x5636924db3f1 in main /builds/worker/workspace/build/src/browser/app/nsBrowserApp.cpp:303:18
    #27 0x7f47152aab96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310
    #28 0x563692430ebc in _start (/home/user/builds/mc-asan/firefox+0x9bebc)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /builds/worker/workspace/build/src/ipc/glue/MessageLink.cpp:151:5 in mozilla::ipc::ProcessLink::SendMessage(IPC::Message*)

Comment 1

[Andrew McCreight [:mccr8]]

The test case involves a postMessage to a shared worker of a very large array buffer:
const buffer = new ArrayBuffer(900767570)
Maybe there's some unchecked OOM failure?

Comment 2

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

When ASan says SEGV on unknown address 0x000000000001, it's almost certainly a MOZ_CRASH. The definition of MOZ_CRASH explains why it's like that.

In this case, it's not an OOM and it's not the absence of a check, but it is caused by that large object size; as the crash stack indicates, it's this familiar line:

    MOZ_CRASH("IPC message size is too large");

Comment 3

[Nika Layzell [:nika] (ni? for response)]

The issue here appears to be that we don't trigger an error when sending a too-large message to a SharedWorker. I expect that this is a general problem for StructuredClone objects sent over IPC. We should probably add a size limit check to Structured Clone serializations which are destined to be sent over IPC, like we do with messages sent over framescripts.

Comment 4

[Simon Giesecke [:sg] [he/him]]

What should be the behaviour of the postMessage call in that case? Throw a TypeError?

Comment 5

[Tyson Smith [:tsmith]]

(In reply to Simon Giesecke [:sg] [he/him] from comment #4)

What should be the behaviour of the postMessage call in that case? Throw a TypeError?

Hi Simon, the fuzzers are still frequently hitting this issue. Who is this question directed at? Can you please set a ni?

Comment 6

[Simon Giesecke [:sg] [he/him]]

Nika, could you provide an answer to the question in comment 4?

Comment 7

[Tyson Smith [:tsmith]]

A Pernosco session is available here: https://pernos.co/debug/0e4fRxye2EowIGo2jzmcsg/index.html

Comment 8

[Bugmon [:jkratzer for issues]]

Bugmon Analysis:
Verified bug as reproducible on mozilla-central 20210224215151-69be3221f49a.

Comment 9

[Nika Layzell [:nika] (ni? for response)]

(In reply to Simon Giesecke [:sg] [he/him] from comment #4)

What should be the behaviour of the postMessage call in that case? Throw a TypeError?

Unfortunately for us, according to the standard we shouldn't throw an error at all, and attempts to send extremely large payloads should just work even though they'll cause massive browser jank issues. Given that the other option right now for us is to perform a hard crash though, I suppose throwing an error is fine.

Given that this exception is nonstandard it doesn't matter a ton what we do here, but a TypeError or RangeError seems like it would probably be fine, though I could also see the argument for us to throw DataCloneError, as it's an error happening due to an invalid output from the structured clone algorithm.

In the future we probably want to grow support for sending arbitrarily large structured clone payloads despite the jank issues, but we unfortunately don't have a great solution for that right now.

Comment 10

[Jason Kratzer [:jkratzer]]

The fuzzers are frequently tripping over this issue and has been marked as a fuzzblocker. Please prioritize this issue accordingly.

Comment 11

[Jens Stutte [:jstutte]]

Olli, can you take a look here? Thank you

Comment 12

[Jens Stutte [:jstutte]]

Jason, I tried to trigger bugmon but it did not run. Am I missing something?

Comment 13

[Jens Stutte [:jstutte]]

Ups, auto-completion did set the wrong ni?, thanks for catching.

Comment 14

[Jason Kratzer [:jkratzer]]

:jstutte, this was never picked up because at the moment, we limit bugmon to issues no older than 2020-03-01. There shouldn't be anything that prevents us from running it on older bugs at this point. But, until I enable a wider search range, feel free to NI me on any bug you need analyzed.

Comment 15

[Bugmon [:jkratzer for issues]]

Bugmon Analysis
Verified bug as reproducible on mozilla-central 20220224093648-2eda0885cbad.