Crash [@ mozilla::ipc::PBackgroundChild::SendPEndpointForReportConstructor]
Categories
(Core :: DOM: Security, 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
| Reporter | ||
Comment 1•3 months ago
|
||
Comment 2•3 months ago
|
||
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)
Comment 3•3 months ago
|
||
The severity field is not set for this bug.
:freddy, could you have a look please?
For more information, please visit BugBot documentation.
Comment 4•3 months ago
|
||
Andreas, did you work on Reporting API last?
Comment 5•3 months ago
|
||
Simon is currently working on Reporting API. Simon, any idea on why we get this?
Comment 6•3 months ago
|
||
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.
| Reporter | ||
Comment 7•3 months ago
|
||
(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?
Comment 8•3 months ago
|
||
(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?
| Reporter | ||
Comment 9•3 months ago
•
|
||
Comment 10•2 months ago
|
||
(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::SetIsActiveand the#ifdef DEBUGinside 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?
Comment 11•2 months ago
|
||
On PTO today but that assert dumps the js stack and native stack with it. Could you paste it here? But agreed, separate bug.
Comment 12•2 months ago
|
||
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?
| Reporter | ||
Comment 13•2 months ago
|
||
| Reporter | ||
Comment 14•2 months ago
|
||
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.
Comment 15•2 months ago
|
||
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?
Comment 16•2 months ago
|
||
The patch in bug 2013863 completely removes SendPEndpointForReportConstructor. So if that is the actual offender, it should be solved by that patch.
Comment 17•1 month ago
|
||
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.
| Reporter | ||
Comment 18•1 month ago
|
||
:sfarre, was this fixed via bug 2013863?
Comment 19•1 month ago
|
||
(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.
Description
•