Closed Bug 2000587 Opened 9 months ago Closed 9 months ago

Crash [@ JS::GetExecutionGlobalFromJSMicroTask(JSObject*)]

Categories

(Core :: JavaScript Engine, defect, P1)

x86_64
Linux
defect

Tracking

()

VERIFIED FIXED
147 Branch
Tracking Status
firefox-esr115 --- unaffected
firefox-esr140 --- unaffected
firefox145 --- disabled
firefox146 --- disabled
firefox147 --- verified

People

(Reporter: decoder, Assigned: arai)

References

(Regression)

Details

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

Crash Data

Attachments

(6 files)

The following testcase crashes on mozilla-central revision 20251116-69c8e4489245 (opt build, run with --fuzzing-safe --ion-offthread-compile=off --more-compartments test-indirect.js):

newGlobal().Promise.resolve().then(() => {})
nukeAllCCWs()

Backtrace:

received signal SIGSEGV, Segmentation fault.
#0  0x0000be8c9c89038c in JS::GetExecutionGlobalFromJSMicroTask(JSObject*) ()
#1  0x0000be8c9c875450 in js::InternalJobQueue::runJobs(JSContext*) ()
#2  0x0000be8c9c796150 in RunShellJobs(JSContext*) ()
#3  0x0000be8c9c769104 in main ()
x0	0x715012d8	38274354647768
x1	0x9d0d1db8	209511139581368
x2	0x3	3
x3	0x1	1
x4	0x9d0d4d58	209511139593560
x5	0x17f	383
x6	0x0	0
x7	0x0	0
x8	0x0	0
x9	0x1e67	7783
x10	0x9ba55917	209511116003607
x11	0x0	0
x12	0x0	0
x13	0x0	0
x14	0xfc000	1032192
x15	0x0	0
x16	0x1	1
x17	0x4a784fb0	256402207035312
x18	0x0	0
x19	0xa423a00	256401129748992
x20	0xa434100	256401129816320
x21	0xfdfe5330	281474943046448
x22	0xfdfe5300	281474943046400
x23	0x0	0
x24	0xa51e1f0	256401130775024
x25	0x0	-1829587348619264
x26	0xa434168	256401129816424
x27	0xa434118	256401129816344
x28	0xfdfe5308	281474943046408
x29	0xfdfe52c0	281474943046336
x30	0x9c875450	209511130813520
sp	0xfdfe52b0	281474943046320
pc	0xbe8c9c89038c <JS::GetExecutionGlobalFromJSMicroTask(JSObject*)+604>
cpsr	[ EL=0 BTYPE=0 SSBS C ]
fpcsr	void
fpcr	0x0	0
=> 0xbe8c9c89038c <_ZN2JS33GetExecutionGlobalFromJSMicroTaskEP8JSObject+604>:	str	x9, [x8]
   0xbe8c9c890390 <_ZN2JS33GetExecutionGlobalFromJSMicroTaskEP8JSObject+608>:	bl	0xbe8c9c01b118 <abort>

Fuzzblocker, marking s-s until checked out.

Attached file Testcase

Verified bug as reproducible on mozilla-central 20251117095036-338a6e3364af.
The bug appears to have been introduced in the following build range:

Start: 0ecf73d86765a2f666eb6731435e2cd7867e750f (20251113150613)
End: 2053be8ca52cb59d95eebef913b26254ab61995c (20251113164320)
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=0ecf73d86765a2f666eb6731435e2cd7867e750f&tochange=2053be8ca52cb59d95eebef913b26254ab61995c

Whiteboard: [bugmon:update,bisect][fuzzblocker] → [bugmon:update,bisected,confirmed][fuzzblocker]

With the old microtask queue, this testcase throws an exception ("TypeError: can't access dead object").

I think it's a missing check for dead wrappers here. I don't think this is security-sensitive: if we reach this code with a dead wrapper, we will always MOZ_CRASH.

It's slightly tricky to fix because this code doesn't have a JSContext available to report errors. Its callers generally seem to expect it to be infallible

Arai, you reviewed this code for Matt (who is currently travelling). Do you remember enough of the context to be able to propose a fix, or should we wait for Matt to be back?

Flags: needinfo?(arai.unmht)

Good find!

So, the new microtask code's assumption around dead-wrapper-ness is mostly based on the gecko's case, where entering the microtask checkpoint would already guarantee the global being alive.
But indeed, directly nuking the CCWs with the test API will break it.

And I think having a dead wrapper check everywhere won't so much hurt the performance, and also it's safer in long term.
so I'm leaning toward adding dead wrapper checks to those APIs and consumers.
I'll look into it.

Attached file (secure)
Assignee: nobody → arai.unmht
Status: NEW → ASSIGNED
Attached file (secure)
Attached file (secure)
Attached file (secure)
Flags: needinfo?(arai.unmht)

Based on comment #3, this bug contains a bisection range found by bugmon. However, the Regressed by field is still not filled.

:arai, if possible, could you fill the Regressed by field and investigate this regression?

For more information, please visit BugBot documentation.

Flags: needinfo?(arai.unmht)
Severity: -- → S3
Priority: -- → P1
Flags: needinfo?(arai.unmht)
Regressed by: 1997192

Set release status flags based on info from the regressing bug 1997192

Given this has been behind a pref, and it's enabled in bug 1997192 from 147, this is effectively nightly only.
I'll land the patches without sec approval requests.

Keywords: sec-other

Verified bug as fixed on rev mozilla-central 20251119215322-e4b3aaadb10a.
Removing bugmon keyword as no further action possible. Please review the bug and re-add the keyword for further analysis.

Status: RESOLVED → VERIFIED
Keywords: bugmon
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: