Open Bug 2007146 Opened 3 months ago Updated 1 month ago

Crash [@ mozilla::ipc::PBackgroundChild::SendPEndpointForReportConstructor]

Categories

(Core :: DOM: Security, defect)

x86_64
Linux
defect

Tracking

()

People

(Reporter: jkratzer, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: testcase, Whiteboard: [bugmon:bisected,confirmed])

Crash Data

Attachments

(2 files)

Testcase found while fuzzing mozilla-central rev 5223c4218ee6 (built with: --enable-address-sanitizer --enable-fuzzing).

Testcase can be reproduced using the following commands:

$ pip install fuzzfetch grizzly-framework pipx --upgrade
$ python -m pipx ensurepath
$ fuzzfetch --build 5223c4218ee6 --asan --fuzzing  -n firefox
$ grizzly-replay-bugzilla ./firefox/firefox <bugid>
[@ mozilla::ipc::PBackgroundChild::SendPEndpointForReportConstructor]

    =================================================================
    ==508276==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x77d856515e1c bp 0x7ffc5053f870 sp 0x7ffc5053f850 T0)
    ==508276==The signal is caused by a READ memory access.
    ==508276==Hint: address points to the zero page.
        #0 0x77d856515e1c in mozilla::ipc::PBackgroundChild::SendPEndpointForReportConstructor(nsTSubstring<char16_t> const&, mozilla::ipc::PrincipalInfo const&) /builds/worker/workspace/obj-build/ipc/ipdl/PBackgroundChild.cpp:4520:46
        #1 0x77d85fb096b5 in mozilla::dom::ReportDeliver::Record(nsPIDOMWindowInner*, nsTSubstring<char16_t> const&, nsTSubstring<char16_t> const&, nsTSubstring<char16_t> const&, mozilla::dom::ReportBody*) /dom/reporting/ReportDeliver.cpp:281:19
        #2 0x77d85fb19e51 in mozilla::dom::ReportingUtils::Report(nsIGlobalObject*, nsAtom*, nsTSubstring<char16_t> const&, nsTSubstring<char16_t> const&, mozilla::dom::ReportBody*) /dom/reporting/ReportingUtils.cpp:43:3
        #3 0x77d85af010d0 in ReportDeprecation /dom/bindings/BindingUtils.cpp:4121:3
        #4 0x77d85af010d0 in MaybeReportDeprecation /dom/bindings/BindingUtils.cpp:4209:3
        #5 0x77d85af010d0 in mozilla::dom::DeprecationWarning(mozilla::dom::GlobalObject const&, mozilla::dom::DeprecatedOperations) /dom/bindings/BindingUtils.cpp:4229:3
        #6 0x77d85af00619 in mozilla::dom::DeprecationWarning(JSContext*, JSObject*, mozilla::dom::DeprecatedOperations) /dom/bindings/BindingUtils.cpp:4223:3
        #7 0x77d859c06db7 in toBlob /builds/worker/workspace/obj-build/dom/bindings/./OffscreenCanvasBinding.cpp:1405:3
        #8 0x77d859c06db7 in mozilla::dom::OffscreenCanvas_Binding::toBlob_promiseWrapper(JSContext*, JS::Handle<JSObject*>, void*, JSJitMethodCallArgs const&) /builds/worker/workspace/obj-build/dom/bindings/./OffscreenCanvasBinding.cpp:1437:13
        #9 0x77d85aee67d3 in bool mozilla::dom::binding_detail::GenericMethod<mozilla::dom::binding_detail::NormalThisPolicy, mozilla::dom::binding_detail::ConvertExceptionsToPromises>(JSContext*, unsigned int, JS::Value*) /dom/bindings/BindingUtils.cpp:3306:13
        #10 0x77d86225ea0b in CallJSNative /js/src/vm/Interpreter.cpp:490:13
        #11 0x77d86225ea0b in js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) /js/src/vm/Interpreter.cpp:586:12
        #12 0x77d8633c97b0 in js::jit::DoCallFallback(JSContext*, js::jit::BaselineFrame*, js::jit::ICFallbackStub*, unsigned int, JS::Value*, JS::MutableHandle<JS::Value>) /js/src/jit/BaselineIC.cpp:1698:10
        #13 0x77d7c62068d3  ([anon:js-executable-memory]+0x28d3)
    
    ==508276==Register values:
    rax = 0x0000000000000000  rbx = 0x000077d8781add20  rcx = 0x00007bd87a59be85  rdx = 0x000077d8781add20
    rdi = 0x0000000000000128  rsi = 0x000077d8781addf0  rbp = 0x00007ffc5053f870  rsp = 0x00007ffc5053f850
     r8 = 0x000077d850b3cc60   r9 = 0x000000000000001d  r10 = 0x0000000000000009  r11 = 0x0000000000000000
    r12 = 0x000077d8781add20  r13 = 0x000077d8781adca0  r14 = 0x000077d8781addf0  r15 = 0x0000000000000000
    AddressSanitizer can not provide additional info.
    SUMMARY: AddressSanitizer: SEGV (/home/jkratzer/builds/m-c-20251218095601-fuzzing-asan-opt/libxul.so+0x831ee1c) (BuildId: d54f3287d03508259cb1416a4546fab6e41b54cb)
    ==508276==ABORTING
Attached file Testcase

Verified bug as reproducible on mozilla-central 20251220093050-78ff6950573a.
Unable to bisect testcase (Testcase reproduces on start build!):

Start: c4d2fbbff4d00bc27c22ef4c97e0bd958718716e (20241221215318)
End: 5223c4218ee669e9c887458225f7ca8f0a0774e9 (20251218095601)
BuildFlags: BuildFlags(asan=True, tsan=False, debug=False, fuzzing=True, coverage=False, valgrind=False, no_opt=False, fuzzilli=False, nyx=False, searchfox=False, afl=False)

Whiteboard: [bugmon:confirm] → [bugmon:bisected,confirmed]

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

For more information, please visit BugBot documentation.

Flags: needinfo?(fbraun)

Andreas, did you work on Reporting API last?

Severity: -- → S3
Flags: needinfo?(fbraun) → needinfo?(afarre)

Simon is currently working on Reporting API. Simon, any idea on why we get this?

Flags: needinfo?(afarre) → needinfo?(sfarre)

The file you provide is indeed taking the entire process down in debug :jkratzer, but I don't see your fuzzing test being reproduced by the test case you provided.

When running the provided test file, we hit CanonicalBrowsingContext::SetIsActive and the #ifdef DEBUG inside it, taking the browser down with us, but I don't see that being a result of Reporting API.

Needinfoing :farre for this as well.

Flags: needinfo?(sfarre)
Flags: needinfo?(jkratzer)
Flags: needinfo?(afarre)

(In reply to Simon Farre [:sfarre] from comment #6)

The file you provide is indeed taking the entire process down in debug :jkratzer, but I don't see your fuzzing test being reproduced by the test case you provided.

Simon, are you using the ASan build specified in comment 0?

Flags: needinfo?(jkratzer)

(In reply to Jason Kratzer [:jkratzer] from comment #7)

(In reply to Simon Farre [:sfarre] from comment #6)

The file you provide is indeed taking the entire process down in debug :jkratzer, but I don't see your fuzzing test being reproduced by the test case you provided.

Simon, are you using the ASan build specified in comment 0?

No, because the browser gets taken down by the test file you provided in comment 1, even in normal builds. Seemingly even system installs gets taken down (so that one seem to expose a wider issue).

Is the provided example the one you are running in the ASAN build?

Simon, apologies if I'm misunderstanding the question but yes, the stack trace listed in comment 0 is returned by opening the testcase in comment 1 in a build with --enable-address-sanitizer.

(In reply to Simon Farre [:sfarre] from comment #6)

The file you provide is indeed taking the entire process down in debug :jkratzer, but I don't see your fuzzing test being reproduced by the test case you provided.

When running the provided test file, we hit CanonicalBrowsingContext::SetIsActive and the #ifdef DEBUG inside it, taking the browser down with us, but I don't see that being a result of Reporting API.

Needinfoing :farre for this as well.

This happens because ManuallyManagesActiveness() returns false, which in this case probably is because the embedder element is gone. Emilio, you wrote this, do you have any insights? This isn't really connected to this bug though, maybe file a new?

Flags: needinfo?(afarre) → needinfo?(emilio)

On PTO today but that assert dumps the js stack and native stack with it. Could you paste it here? But agreed, separate bug.

I can't reproduce this? Running it locally on a debug build closes the window, but because the test-case calls self.close(), what am I missing?

Flags: needinfo?(emilio) → needinfo?(sfarre)
Attached file prefs.js

Emilio, I can reproduce this via: grizzly-replay-bugzilla --xvfb ~/builds/debug/firefox 2007146 -p prefs.js

Note, the prefs currently used by grizzly cause a startup failure due to bug 2013868. I've attached a working set of prefs here.

I get this, fwiw:

$ grizzly-replay-bugzilla --xvfb ./obj-debug/dist/bin/firefox 2007146 -p prefs.js
[2026-02-02 16:04:36] Loaded Bug 2007146 from Bugzilla
[2026-02-02 16:04:36] Starting Grizzly Replay
[2026-02-02 16:04:36] Browser display mode: xvfb
[2026-02-02 16:04:36] Ignoring: log-limit, timeout
[2026-02-02 16:04:36] Using time limit: 30s, timeout: 45s
[2026-02-02 16:04:36] Repeat: 1, Minimum crashes: 1, Relaunch 1
[2026-02-02 16:04:41] Running test (1/1)...
[2026-02-02 16:04:46] No results detected
[2026-02-02 16:04:46] Shutting down...
[2026-02-02 16:04:46] Done.

Not sure why? But also, you mean you can repro the crash in comment 0, or the assert mentioned in comment 6?

The patch in bug 2013863 completely removes SendPEndpointForReportConstructor. So if that is the actual offender, it should be solved by that patch.

Flags: needinfo?(sfarre)

Testcase crashes using the initial build (mozilla-central 20251218095601-5223c4218ee6) but not with tip (mozilla-central 20260220162739-d46c04335970.)

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

Start: c7ceb6974803ab1267bd02a5c4f653967d9c0a6b (20260218205827)
End: ec4b4b27d1a3ac22e3cb3dfbd0be9941f84fc68a (20260218214503)
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=c7ceb6974803ab1267bd02a5c4f653967d9c0a6b&tochange=ec4b4b27d1a3ac22e3cb3dfbd0be9941f84fc68a

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.

Flags: needinfo?(jkratzer)
Keywords: bugmon

:sfarre, was this fixed via bug 2013863?

Flags: needinfo?(jkratzer) → needinfo?(sfarre)

(In reply to Jason Kratzer [:jkratzer] from comment #18)

:sfarre, was this fixed via bug 2013863?

bug 2013863 fixed a number of things, this segfault included, yes. PBackground is not used at all for Reporting API anymore.

Flags: needinfo?(sfarre)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: