1983744 - Crash in [@ JSContext::realm] with a fuzz testcase

Status: RESOLVED DUPLICATE of bug 1988289

(Core :: JavaScript Engine, defect, P1)

Description

[Mayank Bansal]

Crash report: https://crash-stats.mozilla.org/report/index/090c4a29-74aa-4bd7-aabc-66fbf0250819

Reason:

EXCEPTION_ACCESS_VIOLATION_READ

Top 10 frames:

0  xul.dll  JSContext::realm() const  js/src/vm/JSContext.h:298
0  xul.dll  js::AutoRealm::AutoRealm(JSContext*, JS::PersistentRooted<js::PromiseObject*>...  js/src/vm/Realm-inl.h:61
0  xul.dll  js::OffThreadPromiseTask::run(JSContext*, JS::Dispatchable::MaybeShuttingDown)  js/src/vm/OffThreadPromiseRuntimeState.cpp:137
1  xul.dll  JS::Dispatchable::Run(JSContext*, std::unique_ptr<JS::Dispatchable, JS::Delet...  js/src/jsapi.cpp:3118
1  xul.dll  mozilla::dom::workerinternals::(anonymous namespace)::JSDispatchableRunnable:...  dom/workers/RuntimeService.cpp:661
2  xul.dll  mozilla::dom::WorkerThreadRunnable::Run()  dom/workers/WorkerRunnable.cpp:443
3  xul.dll  nsThread::ProcessNextEvent(bool, bool*)  xpcom/threads/nsThread.cpp:1153
4  xul.dll  NS_ProcessPendingEvents(nsIThread*, unsigned int)  xpcom/threads/nsThreadUtils.cpp:445
5  xul.dll  mozilla::dom::workerinternals::(anonymous namespace)::WorkerThreadPrimaryRunn...  dom/workers/RuntimeService.cpp:2291
6  xul.dll  nsThread::ProcessNextEvent(bool, bool*)  xpcom/threads/nsThread.cpp:1153

Open testcase
Click on run.
Within a few seconds, the tab will crash.

Fuzzer generated using Chatgpt.
Marking s-s for now.

Comment 1

[Mayank Bansal]

Attachment: js realm something crash.html

Comment 2

[Jan de Mooij [:jandem]]

Assuming the stack trace is correct, I think we get a nullptr context here from aWorkerPrivate->GetJSContext() and pass that to JS::Dispatchable::Run. We should check what happens in a debug build.

Comment 3

[Daniel Veditz [:dveditz]]

A random fuzzer that doesn't preserve the actual testcases (what's attached is a testcase-generator) might never hit this bug again. Maybe at the very least save the seed so we can try to run it again?

This particular crash is a null-deref and probably isn't that serious, but we should keep the generator hidden while we explore whether it turns up more interesting results. And even a null-deref crash is worth fixing, especially if it blocks further testing.

Comment 4

[Mayank Bansal]

Attachment: reduced but still intermittent.html

This is a somewhat reduced testcase that removes randomness. It just spinds up promises and workers.
To increase the possibility of the crash, try increasing the parallel count.

Comment 5

[Andrew Sutherland [:asuth] (he/him)]

I need to dig into this more, but from a workers perspective in terms of policies around when we turn off the JS runtime's ability to ask us to dispatch runnables, I think the runnable should have already run or been forbidden from being scheduled, so there's a questions of whether this is just a workers bug. I hope to have an answer on Monday as part of also looking at bug 1980271 and bug 1984739 where it seems like workers may need to narrow our locking.

Comment 6

[Mayank Bansal]

still crashes using the second testcase: https://crash-stats.mozilla.org/report/index/1f1d9fe4-488a-4739-adda-d4b3d0251028#tab-details

Comment 7

[Andrew Sutherland [:asuth] (he/him)]

I think the fix in bug 1988289 is likely to make the crash go away since a StrongWorkerRef will prevent the worker from transitioning beyond Canceling until the async tasks are all completed. (The crash from comment 6 shows us having transitioned beyond Canceling.)

Comment 8

[Mayank Bansal]

Is this bug still s-s?
If yes, Would this bug be considered for bug-bounty?

Comment 9

[Mayank Bansal]

asuth, needinfo for my comment #8.

Comment 10

[Andrew Sutherland [:asuth] (he/him)]

Looking at the current signatures, I only see 1 crash in 148 which is https://crash-stats.mozilla.org/report/index/69551689-801e-4e41-b27f-8a1310260103#tab-details and which is very much something different since it's a case of a WebExtension using CloneInto and the issue of concern was a worker lifecycle issue. Duping forward to bug 1988289 which fixed the problem (and which explains why the test case was reproducing the same problem).

I'm not an expert on the bug bounty program and do not make determinations but I understand that https://www.mozilla.org/en-US/security/client-bug-bounty/ documents it and I think this is saying generally things need to be sec-high or sec-critical:

Typically, the security rating given by the Bounty Committee for a bug must be rated a "sec-high" or "sec-critical" in order for it to be eligible for a bounty. In some circumstances, bounties may be paid for lower-rated bugs as well. (See Security Ratings for details of the rating qualifications.)

Lower down there does seem to be some discretion for some sec-mods but this would not fall under them to my understanding.