Closed Bug 1675755 (CVE-2021-23960) Opened 4 years ago Closed 4 years ago

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

Categories

(Core :: JavaScript Engine, defect, P1)

defect

Tracking

()

VERIFIED FIXED
85 Branch
Tracking Status
firefox-esr78 85+ fixed
firefox83 --- wontfix
firefox84 --- wontfix
firefox85 + fixed

People

(Reporter: sourc7, Assigned: sfink)

References

Details

(Keywords: csectype-wildptr, reporter-external, sec-moderate, Whiteboard: [reporter-external] [client-bounty-form] [verif?][adv-main85+][adv-esr78.7+])

Attachments

(11 files)

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)

  1. Reload the page repeatedly
  2. 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)

  1. 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
Flags: sec-bounty?
Attached file array-split.html
Attached file gdb.log
Attached file valgrind.log
Attached file asan.rare.log
Attached file asan.somecase.log

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

Group: firefox-core-security → javascript-core-security
Component: Security → JavaScript Engine
Product: Firefox → Core

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

Flags: needinfo?(sphink)

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.

(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.

Summary: Crash on GC after redeclare let or const on the browser console [js::gc::Cell::runtimeFromAnyThread (this=0x4b4b4b4b4b4b4b4b)] → Crash on GC after redeclare let or const on the web console [js::gc::Cell::runtimeFromAnyThread (this=0x4b4b4b4b4b4b4b4b)]

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.

(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.

(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.)

Flags: needinfo?(sphink)

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.

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.

(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)

Type: task → defect
Attachment #9186221 - Attachment mime type: text/x-log → text/plain
Attachment #9186220 - Attachment mime type: text/x-log → text/plain
Attachment #9186222 - Attachment mime type: text/x-log → text/plain
Attachment #9186223 - Attachment mime type: text/x-log → text/plain
Severity: -- → S3
Priority: -- → P1

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. ;-)

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.

Assignee: nobody → sphink
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

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

Attached file Bug 1675755 - test

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.
Attachment #9188474 - Flags: sec-approval?
Attachment #9191201 - Flags: sec-approval?

(sec-approval ping)

Flags: needinfo?(dveditz)

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

Flags: needinfo?(dveditz)
Keywords: sec-highsec-moderate

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

Attachment #9188474 - Flags: sec-approval? → sec-approval+
Attachment #9191201 - Flags: sec-approval? → sec-approval+
Flags: sec-bounty? → sec-bounty+

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
Attachment #9188474 - Flags: approval-mozilla-esr78?
Attachment #9191201 - Flags: approval-mozilla-esr78?

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

Approved for 78.7esr.

Attachment #9188474 - Flags: approval-mozilla-esr78? → approval-mozilla-esr78+
Attachment #9191201 - Flags: approval-mozilla-esr78? → approval-mozilla-esr78+
Depends on: 1683736
QA Whiteboard: [post-critsmash-triage]
Flags: qe-verify-
Status: RESOLVED → VERIFIED
Whiteboard: [reporter-external] [client-bounty-form] [verif?] → [reporter-external] [client-bounty-form] [verif?][adv-main85+]
Whiteboard: [reporter-external] [client-bounty-form] [verif?][adv-main85+] → [reporter-external] [client-bounty-form] [verif?][adv-main85+][adv-esr78.7+]
Attached file advisory.txt
Alias: CVE-2021-23960
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: