Closed Bug 1804522 Opened 1 year ago Closed 1 year ago

Crash [@ GetClass]

Categories

(Core :: DOM: Core & HTML, defect)

x86_64
Linux
defect

Tracking

()

RESOLVED DUPLICATE of bug 1814279
Tracking Status
firefox-esr102 --- unaffected
firefox110 --- wontfix
firefox111 --- fixed

People

(Reporter: jkratzer, Unassigned)

References

(Blocks 1 open bug)

Details

(4 keywords, Whiteboard: [bugmon:bisected,confirmed])

Crash Data

Attachments

(1 file)

4.69 KB, application/octet-stream
Details

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

Testcase can be reproduced using the following commands:

$ pip install fuzzfetch grizzly-framework
$ python -m fuzzfetch --build a6095e92ad7a --asan --fuzzing -n firefox
$ python -m grizzly.replay ./firefox/firefox testcase.zip
[@ GetClass]

    =================================================================
    ==176717==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f68eea2e7c3 bp 0x7ffea73b9410 sp 0x7ffea73b9410 T0)
    ==176717==The signal is caused by a READ memory access.
    ==176717==Hint: address points to the zero page.
        #0 0x7f68eea2e7c3 in GetClass /builds/worker/workspace/obj-build/dist/include/js/Object.h:47:56
        #1 0x7f68eea2e7c3 in IsProxy /builds/worker/workspace/obj-build/dist/include/js/Proxy.h:384:10
        #2 0x7f68eea2e7c3 in js::IsWrapper(JSObject const*) /builds/worker/workspace/obj-build/dist/include/js/Wrapper.h:393:10
        #3 0x7f68f038e9b5 in js::IsCrossCompartmentWrapper(JSObject const*) /builds/worker/workspace/obj-build/dist/include/js/Wrapper.h:397:10
        #4 0x7f68f185415f in nsContentUtils::ObjectPrincipal(JSObject*) /dom/base/nsContentUtils.cpp:3401:3
        #5 0x7f68f1f2194c in PrincipalOrNull /dom/base/nsIGlobalObject.cpp:80:10
        #6 0x7f68f1f2194c in nsIGlobalObject::IsSystemPrincipal() const /dom/base/nsIGlobalObject.cpp:405:10
        #7 0x7f68f1f21a34 in nsIGlobalObject::GetRTPCallerType() const /dom/base/nsIGlobalObject.cpp:409:7
        #8 0x7f68f6d69816 in mozilla::dom::PerformanceMainThread::PerformanceMainThread(nsPIDOMWindowInner*, nsDOMNavigationTiming*, nsITimedChannel*) /dom/performance/PerformanceMainThread.cpp:99:41
        #9 0x7f68f6d5ade9 in mozilla::dom::Performance::CreateForMainThread(nsPIDOMWindowInner*, nsIPrincipal*, nsDOMNavigationTiming*, nsITimedChannel*) /dom/performance/Performance.cpp:61:11
        #10 0x7f68f1933283 in nsPIDOMWindowInner::CreatePerformanceObjectIfNeeded() /dom/base/nsGlobalWindowInner.cpp:2484:20
        #11 0x7f68f191b947 in nsPIDOMWindowInner::GetPerformance() /dom/base/nsGlobalWindowInner.cpp:2460:3
        #12 0x7f68eeca6979 in mozilla::net::LoadInfo::GetPerformanceStorage() /netwerk/base/LoadInfo.cpp:2086:57
        #13 0x7f68ef8607d0 in mozilla::net::HttpBaseChannel::MaybeReportTimingData() /netwerk/protocol/http/HttpBaseChannel.cpp:5395:18
        #14 0x7f68ef87656e in mozilla::net::HttpChannelChild::DoPreOnStopRequest(nsresult) /netwerk/protocol/http/HttpChannelChild.cpp:979:3
        #15 0x7f68ef875d76 in mozilla::net::HttpChannelChild::OnStopRequest(nsresult const&, mozilla::net::ResourceTimingStructArgs const&, mozilla::net::nsHttpHeaderArray const&) /netwerk/protocol/http/HttpChannelChild.cpp:924:3
        #16 0x7f68ef8ff3ab in operator() /netwerk/protocol/http/HttpChannelChild.cpp:805:15
        #17 0x7f68ef8ff3ab in std::_Function_handler<void (), mozilla::net::HttpChannelChild::ProcessOnStopRequest(nsresult const&, mozilla::net::ResourceTimingStructArgs const&, mozilla::net::nsHttpHeaderArray const&, nsTArray<mozilla::net::ConsoleReportCollected>&&, bool)::$_23>::_M_invoke(std::_Any_data const&) /builds/worker/fetches/sysroot-x86_64-linux-gnu/usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/bits/std_function.h:316:2
        #18 0x7f68efc38b7c in mozilla::net::ChannelEventQueue::FlushQueue() /netwerk/ipc/ChannelEventQueue.cpp:94:12
        #19 0x7f68efc826f6 in mozilla::net::ChannelEventQueue::ResumeInternal()::CompleteResumeRunnable::Run() /netwerk/ipc/ChannelEventQueue.cpp:152:17
        #20 0x7f68ee9a8b0f in mozilla::SchedulerGroup::Runnable::Run() /xpcom/threads/SchedulerGroup.cpp:140:20
        #21 0x7f68ee9bbff9 in mozilla::RunnableTask::Run() /xpcom/threads/TaskController.cpp:538:16
        #22 0x7f68ee9b30b7 in mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) /xpcom/threads/TaskController.cpp:851:26
        #23 0x7f68ee9b0338 in mozilla::TaskController::ExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) /xpcom/threads/TaskController.cpp:683:15
        #24 0x7f68ee9b0a60 in mozilla::TaskController::ProcessPendingMTTask(bool) /xpcom/threads/TaskController.cpp:461:36
        #25 0x7f68ee9c2101 in operator() /xpcom/threads/TaskController.cpp:187:37
        #26 0x7f68ee9c2101 in mozilla::detail::RunnableFunction<mozilla::TaskController::InitializeInternal()::$_2>::Run() /builds/worker/workspace/obj-build/dist/include/nsThreadUtils.h:546:5
        #27 0x7f68ee9e5330 in nsThread::ProcessNextEvent(bool, bool*) /xpcom/threads/nsThread.cpp:1204:16
        #28 0x7f68ee9efac4 in NS_ProcessNextEvent(nsIThread*, bool) /xpcom/threads/nsThreadUtils.cpp:474:10
        #29 0x7f68f014d1ce in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) /ipc/glue/MessagePump.cpp:85:21
        #30 0x7f68effd0cc7 in RunInternal /ipc/chromium/src/base/message_loop.cc:381:10
        #31 0x7f68effd0cc7 in RunHandler /ipc/chromium/src/base/message_loop.cc:374:3
        #32 0x7f68effd0cc7 in MessageLoop::Run() /ipc/chromium/src/base/message_loop.cc:356:3
        #33 0x7f68f72abe39 in nsBaseAppShell::Run() /widget/nsBaseAppShell.cpp:150:27
        #34 0x7f68fc21f4c8 in XRE_RunAppShell() /toolkit/xre/nsEmbedFunctions.cpp:884:20
        #35 0x7f68effd0cc7 in RunInternal /ipc/chromium/src/base/message_loop.cc:381:10
        #36 0x7f68effd0cc7 in RunHandler /ipc/chromium/src/base/message_loop.cc:374:3
        #37 0x7f68effd0cc7 in MessageLoop::Run() /ipc/chromium/src/base/message_loop.cc:356:3
        #38 0x7f68fc21e495 in XRE_InitChildProcess(int, char**, XREChildData const*) /toolkit/xre/nsEmbedFunctions.cpp:743:34
        #39 0x55cc92d672d4 in content_process_main(mozilla::Bootstrap*, int, char**) /browser/app/../../ipc/contentproc/plugin-container.cpp:57:28
        #40 0x55cc92d67797 in main /browser/app/nsBrowserApp.cpp:359:18
        #41 0x7f6910e5ed8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
        #42 0x7f6910e5ee3f in __libc_start_main csu/../csu/libc-start.c:392:3
        #43 0x55cc92ca5d58 in _start (/home/jkratzer/builds/m-c-20221206034609-fuzzing-asan-opt/firefox+0x111d58) (BuildId: b9f0bebf9f254cb545afdf2492d04f18b97bb33c)
    
    AddressSanitizer can not provide additional info.
    SUMMARY: AddressSanitizer: SEGV /builds/worker/workspace/obj-build/dist/include/js/Object.h:47:56 in GetClass
    ==176717==ABORTING
Attached file Testcase

Verified bug as reproducible on mozilla-central 20221207165436-8e09abeeb445.
The bug appears to have been introduced in the following build range:

Start: 2383d2a30a60e87499a64f3e91e05d16f0802294 (20221129130216)
End: ef54714c8e48232c2786c90ecc29b5fdc58d4e70 (20221129152011)
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=2383d2a30a60e87499a64f3e91e05d16f0802294&tochange=ef54714c8e48232c2786c90ecc29b5fdc58d4e70

Keywords: regression
Whiteboard: [bugmon:confirm,pernosco] → [bugmon:bisected,confirmed]
Group: core-security → dom-core-security
Group: dom-core-security

bug 1778510 messed with performance stuff in the regressing range

Flags: needinfo?(tom)
See Also: → 1778510

A pernosco session for this bug can be found here.

It did, although this seems like a much odder bug. PrincipalOrNull() is in the stack, and that function checks right here if the object is null. It's not, continues on down the stack in nsContentUtils::ObjectPrincipal() and then crashes because it is actually null after-all. I don't know what would cause that...

Flags: needinfo?(tom)

(In reply to Tom Ritter [:tjr] from comment #5)

It did, although this seems like a much odder bug. PrincipalOrNull() is in the stack, and that function checks right here if the object is null. It's not, continues on down the stack in nsContentUtils::ObjectPrincipal() and then crashes because it is actually null after-all.

I don't think we're crashing because the object is null. Presumably the shape or the base shape is null. A Pernosco trace should easily tell us which.

I don't know what would cause that either, but presumably we're accessing the window when it's in an inconsistent state. Pernosco might also be able to tell us why that's happening.

S2 for now, but I'm fairly worried about this, and it should perhaps be S1.

Severity: -- → S2

(In reply to Kris Maglione [:kmag] from comment #6)

(In reply to Tom Ritter [:tjr] from comment #5)

It did, although this seems like a much odder bug. PrincipalOrNull() is in the stack, and that function checks right here if the object is null. It's not, continues on down the stack in nsContentUtils::ObjectPrincipal() and then crashes because it is actually null after-all.

I don't think we're crashing because the object is null. Presumably the shape or the base shape is null. A Pernosco trace should easily tell us which.

I don't know what would cause that either, but presumably we're accessing the window when it's in an inconsistent state. Pernosco might also be able to tell us why that's happening.

S2 for now, but I'm fairly worried about this, and it should perhaps be S1.

There's already a pernosco session for this bug in comment #4.

Ah, it looks like the pernosco session is for a different crash location. I'm trying to record one now for the original stack in comment 0.

This bug has been marked as a regression. Setting status flag for Nightly to affected.

Since the crash volume is low (less than 15 per week), the severity is downgraded to S3. Feel free to change it back if you think the bug is still critical.

For more information, please visit auto_nag documentation.

Severity: S2 → S3

Let's keep this S2 due to comment 6, regardless of the crash volume for now. (NI :marco in case we need something particularly for our bot).
Hi Jason, another ping here for comment 8 to see if we have luck already to get a pernosco session.

Severity: S3 → S2
Flags: needinfo?(mcastelluccio)
Flags: needinfo?(jkratzer)

The bot is only looking at the crash volume and whether the bug is a security bug or not. If the volume is low and the bug doesn't have security implications, it decreases the severity.

Why should this be considered S2 or even S1 given the low volume and the absence of security implications? Note that S1 means "(Catastrophic) Blocks development/testing, may impact more than 25% of users, causes data loss, likely dot release driver, and no workaround available".

Flags: needinfo?(mcastelluccio) → needinfo?(kmaglione+bmo)

See also Bug 1814279 which may be the same issue.

Testcase crashes using the initial build (mozilla-central 20221206034609-a6095e92ad7a) but not with tip (mozilla-central 20230210211019-54d29db98836.)

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

Start: 0d8b0133822d3dcd3120a681c4a71916e15507db (20230209213208)
End: d834a5a53b084ce25e1ed3e81a106d4e80e7ef1c (20230209194646)
Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0d8b0133822d3dcd3120a681c4a71916e15507db&tochange=d834a5a53b084ce25e1ed3e81a106d4e80e7ef1c

Removing bugmon keyword as no further action possible. Please review the bug and re-add the keyword for further analysis.

Keywords: bugmon

Then it's a confirmed dupe as we expected.

Status: NEW → RESOLVED
Closed: 1 year ago
Duplicate of bug: 1814279
Flags: needinfo?(kmaglione+bmo)
Flags: needinfo?(jkratzer)
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: