1675755 - (CVE-2021-23960) Crash on GC after redeclare let or const on the web console [js::gc::Cell::runtimeFromAnyThread (this=0x4b4b4b4b4b4b4b4b)]

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect, P1)

Description

[Irvan Kurniawan [:sourc7]]

Attachment: array-split-reload.html

When mistakenly re-declaration of let or const on the browser console, then reload the page repeatedly or typing string.split("") or string.split(" ") while waiting browser console instant evaluation result, suddenly the tab is crashed. To trigger the crash, on the HTML file it need to initialize one constant variable i.e const x = "A"

Mostly when Firefox Nightly ASAN crash, it shows AddressSanitizer: SEGV on unknown address (pc 0x7fa6e7dbe0b9 bp 0x7ffe338b3620 sp 0x7ffe338b3610 T0) but the unknown address is not showed.

Sometimes Nightly ASAN shows AddressSanitizer: use-after-poison on address 0x27f915ded218 at pc 0x7f4221357bb8 bp 0x7fffb52d8850 sp 0x7fffb52d8848 READ of size 8 at 0x27f915ded218 thread T0 (Web Content)

Rare moment, Nightly ASAN show the unknown address: AddressSanitizer: SEGV on unknown address 0x363339343840 (pc 0x7fdf867b7257 bp 0x7ffe9e3f92b0 sp 0x7ffe9e3f8e20 T0) (reproduced on Firefox Nightly ASAN 2020-10-26) (64-bit)

It seems Nightly ASAN tried to access address 0x363339343840 which is potentially exploitable and worth to investigate further.

I've attached Firefox Nightly ASAN log, full GDB log (launch with command line ./mach run --debugger="gdb-9" --debugger-args="-q --args" --disable-e10s), full valgrind log, and PoC video when reproduce the issue.

Browser tested:

• Firefox 82.0.2 (64-bit) on Arch Linux
• Firefox 78.4.0esr (64-bit) on Arch Linux
• Firefox Nightly 84.0a1 (2020-11-05) (64-bit) on Windows 10
• Firefox Nightly ASAN 84.0a1 (2020-11-05) (64-bit) on Arch Linux

Steps to Reproduce:

Reload the page

1. Visit attached file: array-split-reload.html
2. Enter below text to the console:

const array = string.split("") ↵ (press enter)
const array = string.split("\n") ↵ (press enter)

3. Reload the page repeatedly
4. Tab is crashed.

Console instant evaluation

1. Visit attached file: array-split.html
2. Open Web Developer -> Web Console (Ctrl+Shift+K)
3. Enter below text to the console:

const array = string.split("\n") ↵ (press enter)
const array = string.split("") ↵ (press enter)

4. Type to the console (without press enter):

string.split("")
string.split(" ")
string.split("")
string.split(" ")
string.split("")
string.split("\n")
string.split("")

If above doesn't crash the tab, reload the page, then re-type to the console (without press enter):

string.split("")
string.split(" ")
string.split("")
string.split(" ")
string.split("")

What happened? (actual results)

Gah. Your tab just crashed.

AddressSanitizer:DEADLYSIGNAL
=================================================================
==236847==ERROR: AddressSanitizer: SEGV on unknown address (pc 0x7fa6e7dbe0b9 bp 0x7ffe338b3620 sp 0x7ffe338b3610 T0)
==236847==The signal is caused by a READ memory access.
==236847==Hint: this fault was caused by a dereference of a high value address (see register values below).  Dissassemble the provided pc to learn which register was used.
error: address range table at offset 0x5c90 has an invalid tuple (length = 0) at offset 0x5ca0
    #0 0x7fa6e7dbe0b9 in runtimeFromAnyThread /builds/worker/checkouts/gecko/js/src/gc/Cell.h:335:27
    #1 0x7fa6e7dbe0b9 in IsOwnedByOtherRuntime<js::BaseShape *> /builds/worker/checkouts/gecko/js/src/gc/Marking.cpp:170:23
    #2 0x7fa6e7dbe0b9 in ShouldMark<js::BaseShape *> /builds/worker/checkouts/gecko/js/src/gc/Marking.cpp:885:7
    #3 0x7fa6e7dbe0b9 in void DoMarking<js::BaseShape>(js::GCMarker*, js::BaseShape*) /builds/worker/checkouts/gecko/js/src/gc/Marking.cpp:941:8
    #4 0x7fa6e7dbe04d in bool js::gc::TraceEdgeInternal<js::BaseShape*>(JSTracer*, js::BaseShape**, char const*) /builds/worker/checkouts/gecko/js/src/gc/Marking.cpp:675:5
    #5 0x7fa6e7dc5250 in js::GCMarker::eagerlyMarkChildren(js::Shape*) /builds/worker/checkouts/gecko/js/src/gc/Marking.cpp:1249:13
    #6 0x7fa6e7d94223 in markAndScan<js::Shape> /builds/worker/checkouts/gecko/js/src/gc/Marking.cpp:1032:5
    #7 0x7fa6e7d94223 in traverse<js::Shape *> /builds/worker/checkouts/gecko/js/src/gc/Marking.cpp:1042:3
    #8 0x7fa6e7d94223 in traverseEdge<JSObject *, js::Shape> /builds/worker/checkouts/gecko/js/src/gc/Marking.cpp:1132:3
    #9 0x7fa6e7d94223 in js::GCMarker::processMarkStackTop(js::SliceBudget&) /builds/worker/checkouts/gecko/js/src/gc/Marking.cpp:2102:3
    #10 0x7fa6e7d93422 in js::GCMarker::markUntilBudgetExhausted(js::SliceBudget&, js::GCMarker::ShouldReportMarkTime) /builds/worker/checkouts/gecko/js/src/gc/Marking.cpp:1835:7
    #11 0x7fa6e7d4331a in js::gc::GCRuntime::markUntilBudgetExhausted(js::SliceBudget&, js::GCMarker::ShouldReportMarkTime) /builds/worker/checkouts/gecko/js/src/gc/GC.cpp:5662:17
    #12 0x7fa6e7d523de in js::gc::GCRuntime::incrementalSlice(js::SliceBudget&, mozilla::Maybe<JSGCInvocationKind> const&, JS::GCReason, js::gc::AutoGCSession&) /builds/worker/checkouts/gecko/js/src/gc/GC.cpp:6795:13
    #13 0x7fa6e7d55ed5 in js::gc::GCRuntime::gcCycle(bool, js::SliceBudget, mozilla::Maybe<JSGCInvocationKind> const&, JS::GCReason) /builds/worker/checkouts/gecko/js/src/gc/GC.cpp:7249:3
    #14 0x7fa6e7d58213 in js::gc::GCRuntime::collect(bool, js::SliceBudget, mozilla::Maybe<JSGCInvocationKind> const&, JS::GCReason) /builds/worker/checkouts/gecko/js/src/gc/GC.cpp:7484:9
    #15 0x7fa6e7d32de3 in gcSlice /builds/worker/checkouts/gecko/js/src/gc/GC.cpp:7575:3
    #16 0x7fa6e7d32de3 in js::gc::GCRuntime::gcIfRequested() /builds/worker/checkouts/gecko/js/src/gc/GC.cpp:7769:7
    #17 0x7fa6e7d0345b in gcIfNeededAtAllocation /builds/worker/checkouts/gecko/js/src/gc/Allocator.cpp:451:5
    #18 0x7fa6e7d0345b in bool js::gc::GCRuntime::checkAllocatorState<(js::AllowGC)1>(JSContext*, js::gc::AllocKind) /builds/worker/checkouts/gecko/js/src/gc/Allocator.cpp:406:10
    #19 0x7fa6e7d05674 in JSString* js::AllocateStringImpl<JSString, (js::AllowGC)1>(JSContext*, js::gc::InitialHeap) /builds/worker/checkouts/gecko/js/src/gc/Allocator.cpp:209:15
    #20 0x7fa6e717665d in AllocateString<JSThinInlineString, js::CanGC> /builds/worker/checkouts/gecko/js/src/gc/Allocator.h:61:32
    #21 0x7fa6e717665d in new_<js::CanGC> /builds/worker/checkouts/gecko/js/src/vm/StringType-inl.h:322:10
    #22 0x7fa6e717665d in AllocateInlineString<js::CanGC, unsigned char> /builds/worker/checkouts/gecko/js/src/vm/StringType-inl.h:35:31
    #23 0x7fa6e717665d in NewInlineString<js::CanGC, unsigned char> /builds/worker/checkouts/gecko/js/src/vm/StringType-inl.h:63:25
    #24 0x7fa6e717665d in JSLinearString* js::Int32ToString<(js::AllowGC)1>(JSContext*, int) /builds/worker/checkouts/gecko/js/src/jsnum.cpp:816:7
    #25 0x7fa6e79fd6ee in js::IdVectorToArray(JSContext*, JS::Handle<JS::GCVector<JS::PropertyKey, 0ul, js::TempAllocPolicy> >) /builds/worker/checkouts/gecko/js/src/debugger/Frame.cpp:1926:23
    #26 0x7fa6e7a8c431 in js::DebuggerObject::CallData::getOwnPropertyNamesMethod() /builds/worker/checkouts/gecko/js/src/debugger/Object.cpp:778:24
    #27 0x7fa6e7aad28e in bool js::DebuggerObject::CallData::ToNative<&(js::DebuggerObject::CallData::getOwnPropertyNamesMethod())>(JSContext*, unsigned int, JS::Value*) /builds/worker/checkouts/gecko/js/src/debugger/Object.cpp:243:10
    #28 0x7fa652f6344f  (<unknown module>)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /builds/worker/checkouts/gecko/js/src/gc/Cell.h:335:27 in runtimeFromAnyThread
==236847==ABORTING
JavaScript error: resource:///modules/ContentCrashHandlers.jsm, line 50: TypeError: can't access property "permanentKey", browser is undefined

Comment 1

[Irvan Kurniawan [:sourc7]]

Attachment: array-split.html

Comment 2

[Irvan Kurniawan [:sourc7]]

Attachment: gdb.log

Comment 3

[Irvan Kurniawan [:sourc7]]

Attachment: valgrind.log

Comment 4

[Irvan Kurniawan [:sourc7]]

Attachment: asan.rare.log

Comment 5

[Irvan Kurniawan [:sourc7]]

Attachment: asan.somecase.log

Comment 6

[Irvan Kurniawan [:sourc7]]

Attachment: Mozilla Firefox Crash - GC redeclare const then reload.mp4

Comment 7

[Irvan Kurniawan [:sourc7]]

Attachment: Mozilla Firefox Crash - GC after redeclare const then instant evaluation - use-after-poison.mp4

PoC video when Firefox ASAN shows use-after-poison.

Comment 8

[Jan de Mooij [:jandem]]

Steve, needinfo'ing you since this looks GC-related and it's end of day here...

Comment 9

[Steve Fink [:sfink] [:s:]]

Great report, thank you!

I'm still trying to reproduce. I tried with Firefox Nightly ASAN 84.0a1, both 2020-10-23 and build ID 20201106041434. I'll try with one of the nightlies from 2020-11-05 next.

The stack in comment 0, as well as the gdb log, show the GC traversing an edge from a JSObject to a Shape, and the Shape pointer points to a previously swept portion of the heap. That object should have marked through that edge and kept it alive. (Or if that edge was written to it, then it should have marked the Shape* with a pre-barrier before moving it.)

I was thinking that maybe hitting a redeclaration error would leave a half-initialized object with a Shape pointer that gets conditionally traversed during marking, or something like that, but I couldn't spot anything obvious when looking at the callers of code that emits JSMSG_REDECLARED_VAR. This would presumably be done with a Debugger eval.

Comment 10

[Irvan Kurniawan [:sourc7]]

(In reply to Steve Fink [:sfink] [:s:] from comment #9)

Great report, thank you!

I'm still trying to reproduce. I tried with Firefox Nightly ASAN 84.0a1, both 2020-10-23 and build ID 20201106041434. I'll try with one of the nightlies from 2020-11-05 next.

The stack in comment 0, as well as the gdb log, show the GC traversing an edge from a JSObject to a Shape, and the Shape pointer points to a previously swept portion of the heap. That object should have marked through that edge and kept it alive. (Or if that edge was written to it, then it should have marked the Shape* with a pre-barrier before moving it.)

I was thinking that maybe hitting a redeclaration error would leave a half-initialized object with a Shape pointer that gets conditionally traversed during marking, or something like that, but I couldn't spot anything obvious when looking at the callers of code that emits JSMSG_REDECLARED_VAR. This would presumably be done with a Debugger eval.

Thanks Steve for the detailed explanation, it helps me understand better.

To help reproduce the issue, you can watch the attached video: Mozilla Firefox Crash - GC redeclare const then reload.mp4, on that video I take steps:

1. I'm visiting array-split-reload.html
2. Open Web Developer -> Web Console (Ctrl+Shift+K)
3. On the Web Console
4. Type const array = string.split("") press enter
5. Type const array = string.split("\n") press enter
6. Reload the page several times
7. Tab crashed

In the array-split-reload.html file, it allocate large memory to help trigger the GC. After we redeclare const in the web console, then reload the page several times (memory also increased), when GC is triggered, the tab is crashed.

Comment 11

[Steve Fink [:sfink] [:s:]]

Yes, I watched both videos, and followed your instructions. Both the videos and your instructions were very clear. It didn't crash for me using either approach. On Monday, I'll try using the Nightly from the same day. (I'm on Fedora.)

This is asking a lot, but one way to track this down would be if you packed up an rr recording ( https://rr-project.org/ ). I could either replay it locally or upload it to Pernosco. But I will continue trying to reproduce locally.

Comment 12

[Irvan Kurniawan [:sourc7]]

(In reply to Steve Fink [:sfink] [:s:] from comment #11)

Yes, I watched both videos, and followed your instructions. Both the videos and your instructions were very clear. It didn't crash for me using either approach. On Monday, I'll try using the Nightly from the same day. (I'm on Fedora.)

This is asking a lot, but one way to track this down would be if you packed up an rr recording ( https://rr-project.org/ ). I could either replay it locally or upload it to Pernosco. But I will continue trying to reproduce locally.

I've recorded the crash with rr w/ command line ./mach run --debugger="rr" --debugger-args="record" --disable-e10s:
RR recording: https://drive.google.com/file/d/1GGRhqgwy0avh3xn-o7o3vlK-3QuP2Jar/view?usp=sharing
Firefox compiled dist folder: https://drive.google.com/file/d/14hiQumygtivly3vJczma0Fz_1V1S4ok5/view?usp=sharing (in my case GDB tried to find this, if my external drive unmounted when run rr replay)

The default dist folder path in my laptop is: /run/media/sourc7/c2fdf084-509b-4e39-9382-44d4b31d173e/external/mozilla-central-valgrind/obj-x86_64-pc-linux-gnu/dist so when run rr replay, GDB will point to that folder.

Comment 13

[Steve Fink [:sfink] [:s:]]

(Darn it, I typed this in yesterday and forgot to hit Save Changes. I'll be trying out that uploaded trace right now.)

Oh, wow, thanks! I kicked off a download, but can you run rr pack to get everything it needs to replay into the trace directory? That should remove the need for a separate folder and make sure that everything it needs is in the right place, without worrying about the external drive. It may make it very large, though, even larger than it already is. I probably won't have time to look at this until tomorrow, but as soon as I get a chance I'll try with the existing 2 uploads you provided.

Thank you!

(I was still unable to reproduce the crash with the 2020-11-05 Nightly ASAN build for some reason, so this recording should be very helpful.)

Comment 14

[Steve Fink [:sfink] [:s:]]

Oh, from the filename it looks like you did use rr pack?

Sadly, I'm getting Trace XCR0 value 0x2e7 != our XCR0 value 0x1f; Replay will probably fail because glibc dynamic loader examines XCR0 followed by an assertion. But I may still be able to use it.

Comment 15

[Steve Fink [:sfink] [:s:]]

Ok, I made my way through the submission process, and unfortunately it fails because AVX512 was used. Would you be able to resubmit by running with

./mach run --debugger="rr" --debugger-args="record --disable-cpuid-features-ext 0xdc230000,0x2c42,0xc" --disable-e10s

At least, that's what it's asking me to do. Hopefully that isn't dependent on the CPU I am running.

I tried running the binary in your dist upload, but it wants a newer libc than I have. Perhaps it's time for me to upgrade.

Comment 16

[Irvan Kurniawan [:sourc7]]

(In reply to Steve Fink [:sfink] [:s:] from comment #15)

Oh, from the filename it looks like you did use rr pack?

Yes I'm run rr pack then archive the folder with .tar.lz4

Ok, I made my way through the submission process, and unfortunately it fails because AVX512 was used. Would you be able to resubmit by running with

./mach run --debugger="rr" --debugger-args="record --disable-cpuid-features-ext 0xdc230000,0x2c42,0xc" --disable-e10s

At least, that's what it's asking me to do. Hopefully that isn't dependent on the CPU I am running.

I tried running the binary in your dist upload, but it wants a newer libc than I have. Perhaps it's time for me to upgrade.

Sure, I've launched compiled Firefox with above command line, here the rr packed trace link: https://drive.google.com/file/d/1hGiuodIAzmNtAKzgO1cZk6hHfXbG97JV/view?usp=sharing (on this recording, the tab crash on single reload)

Comment 17

[Steve Fink [:sfink] [:s:]]

I finally managed to get this uploaded to Pernosco with source code and everything. It was still a pain to track down, but I think I have it.

The problem is that a Shape is given a cross-zone pointer to a BaseShape. These should very much not be cross-zone edges, and are not handled as such. As a result, there is a GC that does not include the Shape's Zone, so nothing marks the BaseShape and it gets freed. In detail:

There's obj, a js::LexicalEnvironmentObject.

• major GC #9: obj is traced as the environment chain of an Interpreter frame
• obj->shape runs Shape::cachify, which creates a new owned BaseShape* in the wrong Zone (because the cx's is not in the Shape's Realm.)
• major GC #10: obj is not traced because its zone is not collected. The base shape is freed.
• major GC #11: obj is traced as a Realm's global lexical environment, which traces obj->shape->baseShape and crashes.

The stack where the BaseShape is constructed is:

#0  js::Shape::makeOwnBaseShape (this=0x232b42655600, cx=0x55d7f3ef1630) at js/src/vm/Shape.cpp:136
#1  js::Shape::ensureOwnBaseShape (this=0x232b42655600, cx=<optimized out>) at js/src/vm/Shape.h:1055
#2  js::Shape::cachify (cx=0x55d7f3ef1630, shape=0x232b42655600) at js/src/vm/Shape.cpp:205
#3  0x00007f4d94ec8af7 in js::Shape::maybeCreateCacheForLookup (this=0x232b42655600, cx=0x55d7f3ef1630) at js/src/vm/Shape-inl.h:54
#4  js::Shape::search<(js::MaybeAdding)0> (cx=0x55d7f3ef1630, start=0x232b42655600, id=...) at js/src/vm/Shape-inl.h:83
#5  js::Shape::search (this=0x232b42655600, cx=0x55d7f3ef1630, id=...) at js/src/vm/Shape-inl.h:37
#6  js::LookupOwnPropertyInline<(js::AllowGC)1> (cx=0x55d7f3ef1630, obj=..., id=..., propp=..., donep=<optimized out>) at js/src/vm/NativeObject-inl.h:795
#7  js::LookupPropertyInline<(js::AllowGC)1> (cx=0x55d7f3ef1630, obj=..., id=..., objp=..., propp=...) at js/src/vm/NativeObject-inl.h:881
#8  js::LookupProperty (cx=0x55d7f3ef1630, obj=..., id=..., objp=..., propp=...) at js/src/vm/JSObject.cpp:2174
#9  0x00007f4d950f2419 in js::DebuggerObject::forceLexicalInitializationByName (cx=0x55d7f3ef1630, object=..., id=..., result=@0x7ffde1b170af: false) at js/src/debugger/Object.cpp:2384
#10 0x00007f4d950f20f9 in js::DebuggerObject::CallData::forceLexicalInitializationByNameMethod (this=0x7ffde1b170f0) at js/src/debugger/Object.cpp:1084
#11 0x00007f4d950ffbe3 in js::DebuggerObject::CallData::ToNative<&js::DebuggerObject::CallData::forceLexicalInitializationByNameMethod> (cx=0x55d7f3ef1630, argc=<optimized out>, vp=<optimized out>) at js/src/debugger/Object.cpp:243
#12 0x00007f4d94d2396b in CallJSNative (cx=0x55d7f3ef1630, native=0x7f4d950ffb20 <js::DebuggerObject::CallData::ToNative<&js::DebuggerObject::CallData::forceLexicalInitializationByNameMethod>(JSContext*, unsigned int, JS::Value*)>, reason=<optimized out>, args=...) at js/src/vm/Interpreter.cpp:507
#13 js::InternalCallOrConstruct (cx=0x55d7f3ef1630, args=..., construct=<optimized out>, reason=<optimized out>) at js/src/vm/Interpreter.cpp:599
#14 0x00007f4d94d24227 in InternalCall (cx=<optimized out>, args=..., reason=js::CallReason::Call) at js/src/vm/Interpreter.cpp:664
#15 0x00007f4d952c6ee9 in js::jit::DoCallFallback (cx=0x55d7f3ef1630, frame=0x7ffde1b17690, stub=<optimized out>, argc=<optimized out>, vp=<optimized out>, res=...) at js/src/jit/BaselineIC.cpp:3010
#16 0x000026f80999ed68 in ?? ()

I'm honestly not familiar with when the right time is to switch Realms here -- at the low-level, before allocating, or at the semantically meaningful level of looking up a property. But I'll do one and find out via a review. ;-)

Comment 18

[Steve Fink [:sfink] [:s:]]

Oh. Further note that there is a MOZ_ASSERT that would catch this in a debug build: MOZ_ASSERT(cx->zone() == zone()) in Shape::makeOwnBaseShape. So clearly, it is expected that the higher-level code would have entered the correct compartment.

Comment 19

[Steve Fink [:sfink] [:s:]]

Attachment: Bug 1675755 - Enter correct compartment before we might allocate BaseShape

Comment 20

[Irvan Kurniawan [:sourc7]]

Alright great! After applied Diff 368924 on changeset: 42e7e98c701d3e8c8c66a5acca0f0aeeb5076661. I confirmed I no longer able to reproduce the crash.

Comment 21

[Steve Fink [:sfink] [:s:]]

Attachment: Bug 1675755 - test

Comment 22

[Steve Fink [:sfink] [:s:]]

Comment on attachment 9188474 [details]
Bug 1675755 - Enter correct compartment before we might allocate BaseShape

Security Approval Request

• How easily could an exploit be constructed based on the patch?: Given that it requires Debugger, I don't think it can be triggered via content code.
• Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?: No
• Which older supported branches are affected by this flaw?: (I'm guessing all of them)
• If not all supported branches, which bug introduced the flaw?: None
• Do you have backports for the affected branches?: No
• If not, how different, hard to create, and risky will they be?: Should be very easy, hopefully automatic.
• How likely is this patch to cause regressions; how much testing does it need?: Not risky. The same thing happens in many other code paths, this one was just lacking it.

Comment 23

[Steve Fink [:sfink] [:s:]]

(sec-approval ping)

Comment 24

[Ryan VanderMeulen [:RyanVM]]

Probably not a sec-high if the debugger is needed to trigger it.

Comment 25

[Daniel Veditz [:dveditz]]

Comment on attachment 9188474 [details]
Bug 1675755 - Enter correct compartment before we might allocate BaseShape

sec-approval+, though not technically needed now that I've downgraded the sec severity rating

Comment 26

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/integration/autoland/rev/06985ffb553f09a87e9e6fb63691d52925745b6d
https://hg.mozilla.org/integration/autoland/rev/652b2cbf74eb74d9be090a79163e650ac47d0ae9
https://hg.mozilla.org/mozilla-central/rev/06985ffb553f
https://hg.mozilla.org/mozilla-central/rev/652b2cbf74eb

Comment 27

[Steve Fink [:sfink] [:s:]]

Comment on attachment 9188474 [details]
Bug 1675755 - Enter correct compartment before we might allocate BaseShape

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: I'm ambivalent as to whether this needs to land in esr78. But it's a crasher that can be hit by typing stuff into the web console.
• User impact if declined: If the user uses let and const for exploratory stuff in the console, it's fairly easy to run into this crash. Given that it requires Debugger, and moreover the only straightforward way to hit it is via interactive commands, it would be very difficult to exploit.
• Fix Landed on Version: 85
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): There are many code paths that have to enter the Debuggee realm. There was one place that was missing it. So now it looks more like the rest, and it's hard to come up with a way for it to cause problems.
• String or UUID changes made by this patch: none

Comment 28

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9188474 [details]
Bug 1675755 - Enter correct compartment before we might allocate BaseShape

Approved for 78.7esr.

Comment 29

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr78/rev/f325221d3fb2
https://hg.mozilla.org/releases/mozilla-esr78/rev/7a7b002ee8f9

Comment 30

[Ryan VanderMeulen [:RyanVM]]

Backed out from ESR78 for compartment assertions.
https://hg.mozilla.org/releases/mozilla-esr78/rev/504e1d277a99cff0dd9e768d158a6c24a07eeb13

https://treeherder.mozilla.org/logviewer?job_id=324975063&repo=mozilla-esr78&lineNumber=8221

Comment 31

[Ryan VanderMeulen [:RyanVM]]

Round 2:
https://hg.mozilla.org/releases/mozilla-esr78/rev/92cd757558a1
https://hg.mozilla.org/releases/mozilla-esr78/rev/d83feceb5efb

Comment 32

[Frederik Braun [:freddy]]

Attachment: advisory.txt