Testcase found while fuzzing mozilla-central rev 2f53c261903e (built with: --enable-debug --enable-fuzzing).

I don't think that there's anything particularly dangerous about this but marking as S-S just in case.

Testcase can be reproduced using the following commands:

$ pip install fuzzfetch grizzly-framework
$ python -m fuzzfetch --build 2f53c261903e --debug --fuzzing -n firefox
$ python -m grizzly.replay ./firefox/firefox testcase.html

Hit MOZ_CRASH(invalid UTF-8 string: ReportBufferTooSmall) at /js/src/vm/CharacterEncoding.cpp:294

    ==588262==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f5932c5569d bp 0x7ffddb102940 sp 0x7ffddb102880 T588262)
    ==588262==The signal is caused by a WRITE memory access.
    ==588262==Hint: address points to the zero page.
        #0 0x7f5932c5569d in InflateUTF8ToUTF16<OnUTF8Error::Crash, (lambda at /js/src/vm/CharacterEncoding.cpp:565:14)> /js/src/vm/CharacterEncoding.cpp:294:9
        #1 0x7f5932c5569d in JS::ConstUTF8CharsZ::validate(unsigned long) /js/src/vm/CharacterEncoding.cpp:568:3
        #2 0x7f5932cbc6f1 in ConstUTF8CharsZ /builds/worker/workspace/obj-build/dist/include/js/CharacterEncoding.h:148:5
        #3 0x7f5932cbc6f1 in JSErrorBase::initBorrowedMessage(char const*) /builds/worker/workspace/obj-build/dist/include/js/ErrorReport.h:149:16
        #4 0x7f5932cb9008 in js::ReportErrorVA(JSContext*, js::IsWarning, char const*, js::ErrorArgumentsType, __va_list_tag*) /builds/worker/workspace/obj-build/dist/include/mozilla/UniquePtr.h
        #5 0x7f5932fa0851 in JS::WarnUTF8(JSContext*, char const*, ...) /js/src/vm/Warnings.cpp:55:8
        #6 0x7f592ef41bd8 in mozilla::webgpu::WebGPUChild::JsWarning(nsIGlobalObject*, nsTSubstring<char> const&) /dom/webgpu/ipc/WebGPUChild.cpp:31:7
        #7 0x7f592ef46015 in mozilla::webgpu::WebGPUChild::RecvDeviceUncapturedError(unsigned long, nsTSubstring<char> const&) /dom/webgpu/ipc/WebGPUChild.cpp:1005:7
        #8 0x7f592ef59eba in mozilla::webgpu::PWebGPUChild::OnMessageReceived(IPC::Message const&) /builds/worker/workspace/obj-build/ipc/ipdl/PWebGPUChild.cpp:1654:79
        #9 0x7f592d0684da in mozilla::gfx::PCanvasManagerChild::OnMessageReceived(IPC::Message const&) /builds/worker/workspace/obj-build/ipc/ipdl/PCanvasManagerChild.cpp:422:32
        #10 0x7f592c71e631 in mozilla::ipc::MessageChannel::DispatchAsyncMessage(mozilla::ipc::ActorLifecycleProxy*, IPC::Message const&) /ipc/glue/MessageChannel.cpp:1781:25
        #11 0x7f592c71b185 in mozilla::ipc::MessageChannel::DispatchMessage(mozilla::ipc::ActorLifecycleProxy*, mozilla::UniquePtr<IPC::Message, mozilla::DefaultDelete<IPC::Message> >) /ipc/glue/MessageChannel.cpp:1706:9
        #12 0x7f592c71bd26 in mozilla::ipc::MessageChannel::RunMessage(mozilla::ipc::ActorLifecycleProxy*, mozilla::ipc::MessageChannel::MessageTask&) /ipc/glue/MessageChannel.cpp:1506:3
        #13 0x7f592c71d0b1 in mozilla::ipc::MessageChannel::MessageTask::Run() /ipc/glue/MessageChannel.cpp:1604:14
        #14 0x7f592bb6c55e in mozilla::RunnableTask::Run() /xpcom/threads/TaskController.cpp:475:16
        #15 0x7f592bb46f13 in mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) /xpcom/threads/TaskController.cpp:788:26
        #16 0x7f592bb45ac3 in mozilla::TaskController::ExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) /xpcom/threads/TaskController.cpp:620:15
        #17 0x7f592bb45d33 in mozilla::TaskController::ProcessPendingMTTask(bool) /xpcom/threads/TaskController.cpp:398:36
        #18 0x7f592bb6fd59 in operator() /xpcom/threads/TaskController.cpp:127:37
        #19 0x7f592bb6fd59 in mozilla::detail::RunnableFunction<mozilla::TaskController::InitializeInternal()::$_1>::Run() /builds/worker/workspace/obj-build/dist/include/nsThreadUtils.h:531:5
        #20 0x7f592bb5b7bf in nsThread::ProcessNextEvent(bool, bool*) /xpcom/threads/nsThread.cpp:1180:16
        #21 0x7f592bb61dbd in NS_ProcessNextEvent(nsIThread*, bool) /xpcom/threads/nsThreadUtils.cpp:465:10
        #22 0x7f592c724064 in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) /ipc/glue/MessagePump.cpp:107:5
        #23 0x7f592c64b1c7 in MessageLoop::RunInternal() /ipc/chromium/src/base/message_loop.cc:380:10
        #24 0x7f592c64b0d2 in RunHandler /ipc/chromium/src/base/message_loop.cc:373:3
        #25 0x7f592c64b0d2 in MessageLoop::Run() /ipc/chromium/src/base/message_loop.cc:355:3
        #26 0x7f593088adf8 in nsBaseAppShell::Run() /widget/nsBaseAppShell.cpp:137:27
        #27 0x7f59329c917b in XRE_RunAppShell() /toolkit/xre/nsEmbedFunctions.cpp:875:20
        #28 0x7f592c724faa in mozilla::ipc::MessagePumpForChildProcess::Run(base::MessagePump::Delegate*) /ipc/glue/MessagePump.cpp:235:9
        #29 0x7f592c64b1c7 in MessageLoop::RunInternal() /ipc/chromium/src/base/message_loop.cc:380:10
        #30 0x7f592c64b0d2 in RunHandler /ipc/chromium/src/base/message_loop.cc:373:3
        #31 0x7f592c64b0d2 in MessageLoop::Run() /ipc/chromium/src/base/message_loop.cc:355:3
        #32 0x7f59329c879c in XRE_InitChildProcess(int, char**, XREChildData const*) /toolkit/xre/nsEmbedFunctions.cpp:734:34
        #33 0x55dc34239f60 in content_process_main /browser/app/../../ipc/contentproc/plugin-container.cpp:57:28
        #34 0x55dc34239f60 in main /browser/app/nsBrowserApp.cpp:338:18
        #35 0x7f5942033082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16
        #36 0x55dc3420fd0c in _start (/home/jkratzer/builds/mc-debug/firefox-bin+0x15d0c) (BuildId: 133b6fa9e3c11dc0f9c98e9989cac1e3f5e92ac3)
    
    UndefinedBehaviorSanitizer can not provide additional info.
    SUMMARY: UndefinedBehaviorSanitizer: SEGV /js/src/vm/CharacterEncoding.cpp:294:9 in InflateUTF8ToUTF16<OnUTF8Error::Crash, (lambda at /js/src/vm/CharacterEncoding.cpp:565:14)>
    ==588262==ABORTING

Bugmon Analysis
Verified bug as reproducible on mozilla-central 20220603155506-68727ef04ccf.
The bug appears to have been introduced in the following build range:

Start: 66258377c86f63100b3ec9e17bebbb73929ac219 (20211208152205)
End: 740fad344989d083fad880469a0555ac68010d34 (20211208214306)
Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=66258377c86f63100b3ec9e17bebbb73929ac219&tochange=740fad344989d083fad880469a0555ac68010d34

In the affected range (note: an integration branch link works better when the range is a subset of a single mozilla-central commit) the most likely "regressor" seems to be bug 1743847 which added a ThrowOperationError() call to WebGPU, but I don't see how that's different from other places that call the same. The patch also doubled the length of a fixed error message buffer so maybe prior builds rejected the message as too long and didn't hit the crashing code.

Looks like a safe intentional crash while WebGPU is trying to send a JS warning. But I couldn't reproduce in a regular nightly build (the report is from a debugging/fuzzing build) so maybe something less safe could happen if we didn't go down the same paths. On a nightly I get a warning on the console (Shader '' parsing error: expected global item ('struct', 'let', 'var', 'type', ';', 'fn') or the end of the file, found '') which could be consistent with the stack and the UTF8 error, except it's not a MOZ_CRASH in an opt build. Looks like validate() is only called in a DEBUG build so that tracks.

So is it safe to be slinging invalid UTF8 strings from user content around? I don't believe our JS fuzzers hit an equivalent MOZ_CRASH when they throw garbage at the JS parser. Maybe it's expected that strings like this are sanitized more before calling errors.

(tangent: should this be an error rather than a warning? it says "parsing error" right in the text!)

Jim: please check my assumptions above

Actually, everything from Naga (the shader translator producing that error message) should be valid UTF-8. The "buffer too small" error seems to be this:

// Check that |src| is large enough to hold an n-byte code unit.
if (i + n > srclen) {
  INVALID(ReportBufferTooSmall, /* dummy = */ 0, 1);
}

Note that that's checking i + n, where n is the number of bytes in some character's UTF-8 encoding, against srclen, not any destination thing. (This loop is just validating the UTF-8, so it shouldn't care about any destination size anyway.)

So we've got a truncated UTF-8 character at the end of the error message.

regarding your tangent: WebGPU has an odd error-reporting model, so that validation can occur in the GPU process, not the content process: instead of reporting an error immediately, WebGPU just marks the object affected by the error as invalid and continues on. This lets almost all operations be asynchronous: content doesn't block waiting for confirmation from the GPU process. Then, there's an explicit popErrorScope operation that is synchronous, and reports errors. I haven't looked into this specific crash, but I'm betting that the hard error will get propagated to content via popErrorScope, and it's just being logged as a convenience.

I would say that the fix should involve truncating the message at a proper UTF-8 boundary.

The severity field is not set for this bug.
:jimb, could you have a look please?

For more information, please visit auto_nag documentation.

Bugmon Analysis
Testcase crashes using the initial build (mozilla-central 20220603093350-2f53c261903e) but not with tip (mozilla-central 20220708214204-74604ee44d4f.)

The bug appears to have been fixed in the following build range:

Start: e6e2286d2ac25001127a1cf54a87a95fb435c734 (20220708093332)
End: 807e95cd9956aa4967ddddc80f8ccab4ad370e8d (20220708081410)
Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e6e2286d2ac25001127a1cf54a87a95fb435c734&tochange=807e95cd9956aa4967ddddc80f8ccab4ad370e8d

jkratzer, can you confirm that the above bisection range is responsible for fixing this issue?
Removing bugmon keyword as no further action possible. Please review the bug and re-add the keyword for further analysis.

Nicolas, is it possible that this was fixed via bug 1750576?

Yeah I think it was (accidentally) fixed by https://hg.mozilla.org/mozilla-central/rev/50901e1befca4c30e18e8311649f13a357afce78 which rewrote the code that passes and convert the shader string from content to the device in a more principled way.

:nical, since this bug contains a bisection range, could you fill (if possible) the regressed_by field?
For more information, please visit auto_nag documentation.

It's unclear how any of the patches in the linked range could have caused the regression.