Closed Bug 1725335 (CVE-2021-38496) Opened 3 years ago Closed 3 years ago

AddressSanitizer: heap-use-after-free MessageChannel.cpp:1844 in mozilla::ipc::MessageChannel::MessageTask::Run

Categories

(Core :: IPC, task)

Product:
Core
Component:
IPC
Type:
task

Tracking

()

Status:
VERIFIED FIXED
Milestone:
93 Branch
Tracking Flags:
Tracking Status
firefox-esr78 93+ verified
firefox-esr91 93+ verified
firefox91 --- wontfix
firefox92 --- wontfix
firefox93 + verified

People

(Reporter: m.cooolie, Assigned: nika)

Details

(Keywords: csectype-uaf, sec-high, Whiteboard: [reporter-external] [client-bounty-form] [verif?][sec-survey][adv-main93+][adv-esr78.15+][adv-esr91.2+])

Attachments

(5 files, 1 obsolete file)

poc.zip
72.04 KB, application/x-zip-compressed
Details
demo.mp4
1.76 MB, video/mp4
Details
Bug 1725335 - Streamline ownership and locking in MessageTask, r=#ipc-reviewers
48 bytes, text/x-phabricator-request
RyanVM
: approval-mozilla-esr91+
dveditz
: sec-approval+
Details | Review
Bug 1725335 - (ESR78) Streamline ownership and locking in MessageTask
48 bytes, text/x-phabricator-request
RyanVM
: approval-mozilla-esr78+
Details | Review
advisory.txt
220 bytes, text/plain
Details
Attached file poc.zip —

#Summary
AddressSanitizer: heap-use-after-free MessageChannel.cpp:1844 in mozilla::ipc::MessageChannel::MessageTask::Run

#Reproduce
OS:Win10 X64
Firefox: Nightly 93.0a1 (2021-08-11) (64-bit)

step:

  1. sudo python -m http.server 80
  2. install node puppeteer-core (ffpuppet not work on windows)
  3. node ff.test.js D:\firefox_asan\target\firefox\firefox.exe http://localhost/fuzz1/1628742733366/fuzz-00005.htm
  4. wait for 30s if not crashes try again

I will try to make a minicase.

#Type of crash
Tab process

#Analysis
MessageTask hold a raw pointer to MessageChannel[1] with out correct observation object life cycle and used AT[2].
when mozilla::ShutdownXPCOM, PCompositorManagerChild destruct will free the mChannel[3] cause uaf.

[1]
ipc/glue/MessageChannel.h
553	MessageChannel* mChannel; // found in mozilla::ipc::MessageChannel::MessageTask

[2]
ipc/glue/MessageChannel.cpp
1844 mChannel->AssertWorkerThread(); // found in mozilla::ipc::MessageChannel::MessageTask::Run

[3]
ipc/glue/ProtocolUtils.h
555	MessageChannel mChannel; // found in mozilla::ipc::IToplevelProtocol

#Patch
Not Yet

#ASAN

=================================================================
==11116==ERROR: AddressSanitizer: heap-use-after-free on address 0x12778a4c5f88 at pc 0x7ff8e52cb16a bp 0x00dff11fd570 sp 0x00dff11fd5b8
READ of size 8 at 0x12778a4c5f88 thread T0
    #0 0x7ff8e52cb169 in mozilla::ipc::MessageChannel::MessageTask::Run /builds/worker/checkouts/gecko/ipc/glue/MessageChannel.cpp:1844
    #1 0x7ff8e3f2e75d in mozilla::RunnableTask::Run /builds/worker/checkouts/gecko/xpcom/threads/TaskController.cpp:502
    #2 0x7ff8e3eeaae9 in mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal /builds/worker/checkouts/gecko/xpcom/threads/TaskController.cpp:805
    #3 0x7ff8e3ee692c in mozilla::TaskController::ExecuteNextTaskOnlyMainThreadInternal /builds/worker/checkouts/gecko/xpcom/threads/TaskController.cpp:641
    #4 0x7ff8e3ee72f0 in mozilla::TaskController::ProcessPendingMTTask /builds/worker/checkouts/gecko/xpcom/threads/TaskController.cpp:425
    #5 0x7ff8e3f38bc1 in mozilla::detail::RunnableFunction<`lambda at /builds/worker/checkouts/gecko/xpcom/threads/TaskController.cpp:138:7'>::Run /builds/worker/checkouts/gecko/xpcom/threads/nsThreadUtils.h:532
    #6 0x7ff8e3f0f71b in nsThread::ProcessNextEvent /builds/worker/checkouts/gecko/xpcom/threads/nsThread.cpp:1148
    #7 0x7ff8e3f1fffc in NS_ProcessNextEvent /builds/worker/checkouts/gecko/xpcom/threads/nsThreadUtils.cpp:466
    #8 0x7ff8e3f0d41d in nsThread::Shutdown /builds/worker/checkouts/gecko/xpcom/threads/nsThread.cpp:840
    #9 0x7ff8e6e94a26 in mozilla::layers::ImageBridgeChild::ShutDown /builds/worker/checkouts/gecko/gfx/layers/ipc/ImageBridgeChild.cpp:489
    #10 0x7ff8e6f249b6 in gfxPlatform::ShutdownLayersIPC /builds/worker/checkouts/gecko/gfx/thebes/gfxPlatform.cpp:1340
    #11 0x7ff8e3fafb8f in mozilla::ShutdownXPCOM /builds/worker/checkouts/gecko/xpcom/build/XPCOMInit.cpp:622
    #12 0x7ff8f1a0be30 in XRE_TermEmbedding /builds/worker/checkouts/gecko/toolkit/xre/nsEmbedFunctions.cpp:218
    #13 0x7ff8e52f4b98 in mozilla::ipc::ScopedXREEmbed::Stop /builds/worker/checkouts/gecko/ipc/glue/ScopedXREEmbed.cpp:90
    #14 0x7ff8f1a0cdff in XRE_InitChildProcess /builds/worker/checkouts/gecko/toolkit/xre/nsEmbedFunctions.cpp:753
    #15 0x7ff61d731f49 in NS_internal_main /builds/worker/checkouts/gecko/browser/app/nsBrowserApp.cpp:327
    #16 0x7ff61d7314d4 in wmain /builds/worker/checkouts/gecko/toolkit/xre/nsWindowsWMain.cpp:131
    #17 0x7ff61d82f3f7 in __scrt_common_main_seh f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:288
    #18 0x7ff97f857033 in BaseThreadInitThunk+0x13 (C:\Windows\System32\KERNEL32.DLL+0x180017033)
    #19 0x7ff980ee2650 in RtlUserThreadStart+0x20 (C:\Windows\SYSTEM32\ntdll.dll+0x180052650)

0x12778a4c5f88 is located 264 bytes inside of 592-byte region [0x12778a4c5e80,0x12778a4c60d0)
freed by thread T0 here:
    #0 0x7ff94f755afb in free Z:\task_162801323523615\fetches\llvm-project\llvm\projects\compiler-rt\lib\asan\asan_malloc_win.cpp:82
    #1 0x7ff8e55da72c in mozilla::layers::PCompositorManagerChild::~PCompositorManagerChild /builds/worker/workspace/obj-build/ipc/ipdl/PCompositorManagerChild.cpp:62
    #2 0x7ff8e52ece8e in mozilla::ipc::ActorLifecycleProxy::~ActorLifecycleProxy /builds/worker/checkouts/gecko/ipc/glue/ProtocolUtils.cpp:280
    #3 0x7ff8e54b46d1 in mozilla::layers::PCompositorManagerParent::OnChannelClose /builds/worker/workspace/obj-build/ipc/ipdl/PCompositorManagerChild.cpp:596
    #4 0x7ff8e52d0945 in mozilla::ipc::MessageChannel::Close /builds/worker/checkouts/gecko/ipc/glue/MessageChannel.cpp:2580
    #5 0x7ff8e6e79061 in mozilla::layers::CompositorManagerChild::Shutdown /builds/worker/checkouts/gecko/gfx/layers/ipc/CompositorManagerChild.cpp:79
    #6 0x7ff8e6f249b1 in gfxPlatform::ShutdownLayersIPC /builds/worker/checkouts/gecko/gfx/thebes/gfxPlatform.cpp:1339
    #7 0x7ff8e3fafb8f in mozilla::ShutdownXPCOM /builds/worker/checkouts/gecko/xpcom/build/XPCOMInit.cpp:622
    #8 0x7ff8f1a0be30 in XRE_TermEmbedding /builds/worker/checkouts/gecko/toolkit/xre/nsEmbedFunctions.cpp:218
    #9 0x7ff8e52f4b98 in mozilla::ipc::ScopedXREEmbed::Stop /builds/worker/checkouts/gecko/ipc/glue/ScopedXREEmbed.cpp:90
    #10 0x7ff8f1a0cdff in XRE_InitChildProcess /builds/worker/checkouts/gecko/toolkit/xre/nsEmbedFunctions.cpp:753
    #11 0x7ff61d731f49 in NS_internal_main /builds/worker/checkouts/gecko/browser/app/nsBrowserApp.cpp:327
    #12 0x7ff61d7314d4 in wmain /builds/worker/checkouts/gecko/toolkit/xre/nsWindowsWMain.cpp:131
    #13 0x7ff61d82f3f7 in __scrt_common_main_seh f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:288
    #14 0x7ff97f857033 in BaseThreadInitThunk+0x13 (C:\Windows\System32\KERNEL32.DLL+0x180017033)
    #15 0x7ff980ee2650 in RtlUserThreadStart+0x20 (C:\Windows\SYSTEM32\ntdll.dll+0x180052650)

previously allocated by thread T0 here:
    #0 0x7ff94f755c0b in malloc Z:\task_162801323523615\fetches\llvm-project\llvm\projects\compiler-rt\lib\asan\asan_malloc_win.cpp:98
    #1 0x7ff95ca1139d in moz_xmalloc /builds/worker/checkouts/gecko/memory/mozalloc/mozalloc.cpp:52
    #2 0x7ff8e6e78d34 in mozilla::layers::CompositorManagerChild::Init /builds/worker/checkouts/gecko/gfx/layers/ipc/CompositorManagerChild.cpp:65
    #3 0x7ff8ec883cde in mozilla::dom::ContentChild::RecvInitRendering /builds/worker/checkouts/gecko/dom/ipc/ContentChild.cpp:1542
    #4 0x7ff8e5533a67 in mozilla::dom::PContentChild::OnMessageReceived /builds/worker/workspace/obj-build/ipc/ipdl/PContentChild.cpp:8826
    #5 0x7ff8e52cc854 in mozilla::ipc::MessageChannel::DispatchAsyncMessage /builds/worker/checkouts/gecko/ipc/glue/MessageChannel.cpp:2051
    #6 0x7ff8e52c8cbf in mozilla::ipc::MessageChannel::DispatchMessage /builds/worker/checkouts/gecko/ipc/glue/MessageChannel.cpp:1978
    #7 0x7ff8e52cab3c in mozilla::ipc::MessageChannel::RunMessage /builds/worker/checkouts/gecko/ipc/glue/MessageChannel.cpp:1826
    #8 0x7ff8e52cb0ec in mozilla::ipc::MessageChannel::MessageTask::Run /builds/worker/checkouts/gecko/ipc/glue/MessageChannel.cpp:1857
    #9 0x7ff8e3f2e75d in mozilla::RunnableTask::Run /builds/worker/checkouts/gecko/xpcom/threads/TaskController.cpp:502
    #10 0x7ff8e3eeaae9 in mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal /builds/worker/checkouts/gecko/xpcom/threads/TaskController.cpp:805
    #11 0x7ff8e3ee692c in mozilla::TaskController::ExecuteNextTaskOnlyMainThreadInternal /builds/worker/checkouts/gecko/xpcom/threads/TaskController.cpp:641
    #12 0x7ff8e3ee72f0 in mozilla::TaskController::ProcessPendingMTTask /builds/worker/checkouts/gecko/xpcom/threads/TaskController.cpp:425
    #13 0x7ff8e3f38ba1 in mozilla::detail::RunnableFunction<`lambda at /builds/worker/checkouts/gecko/xpcom/threads/TaskController.cpp:135:7'>::Run /builds/worker/checkouts/gecko/xpcom/threads/nsThreadUtils.h:532
    #14 0x7ff8e3f0f71b in nsThread::ProcessNextEvent /builds/worker/checkouts/gecko/xpcom/threads/nsThread.cpp:1148
    #15 0x7ff8e3f1fffc in NS_ProcessNextEvent /builds/worker/checkouts/gecko/xpcom/threads/nsThreadUtils.cpp:466
    #16 0x7ff8e52d5eae in mozilla::ipc::MessagePump::Run /builds/worker/checkouts/gecko/ipc/glue/MessagePump.cpp:85
    #17 0x7ff8e51e41a5 in MessageLoop::RunHandler /builds/worker/checkouts/gecko/ipc/chromium/src/base/message_loop.cc:324
    #18 0x7ff8e51e3f75 in MessageLoop::Run /builds/worker/checkouts/gecko/ipc/chromium/src/base/message_loop.cc:306
    #19 0x7ff8ed40cfda in nsBaseAppShell::Run /builds/worker/checkouts/gecko/widget/nsBaseAppShell.cpp:137
    #20 0x7ff8ed5f410b in nsAppShell::Run /builds/worker/checkouts/gecko/widget/windows/nsAppShell.cpp:603
    #21 0x7ff8f1a0d934 in XRE_RunAppShell /builds/worker/checkouts/gecko/toolkit/xre/nsEmbedFunctions.cpp:917
    #22 0x7ff8e51e41a5 in MessageLoop::RunHandler /builds/worker/checkouts/gecko/ipc/chromium/src/base/message_loop.cc:324
    #23 0x7ff8e51e3f75 in MessageLoop::Run /builds/worker/checkouts/gecko/ipc/chromium/src/base/message_loop.cc:306
    #24 0x7ff8f1a0cdc7 in XRE_InitChildProcess /builds/worker/checkouts/gecko/toolkit/xre/nsEmbedFunctions.cpp:749
    #25 0x7ff61d731f49 in NS_internal_main /builds/worker/checkouts/gecko/browser/app/nsBrowserApp.cpp:327
    #26 0x7ff61d7314d4 in wmain /builds/worker/checkouts/gecko/toolkit/xre/nsWindowsWMain.cpp:131
    #27 0x7ff61d82f3f7 in __scrt_common_main_seh f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:288
    #28 0x7ff97f857033 in BaseThreadInitThunk+0x13 (C:\Windows\System32\KERNEL32.DLL+0x180017033)

SUMMARY: AddressSanitizer: heap-use-after-free /builds/worker/checkouts/gecko/ipc/glue/MessageChannel.cpp:1844 in mozilla::ipc::MessageChannel::MessageTask::Run
Shadow bytes around the buggy address:
  0x049a7b918ba0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x049a7b918bb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x049a7b918bc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x049a7b918bd0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x049a7b918be0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
=>0x049a7b918bf0: fd[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x049a7b918c00: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x049a7b918c10: fd fd fd fd fd fd fd fd fd fd fa fa fa fa fa fa
  0x049a7b918c20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x049a7b918c30: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x049a7b918c40: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==11116==ABORTING
Flags: sec-bounty?
Attached video demo.mp4 —

Reproduce video

Group: firefox-core-security → dom-core-security
Component: Security → IPC
Product: Firefox → Core

Nika, you've been looking at MessageChannel lifecycle issues recently; any thoughts about this?

Flags: needinfo?(nika)

I spent some time looking over the relevant code, and I think I might've found the source of the issue. It appears as though there are a few places where we iterate over mPending and remove entries which we want to process immediately. This is done without Clear()-ing the entries, and the entries are not skipped if IsScheduled(), which means that we could theoretically remove an entry which is still scheduled to be Run() at some point in these places: https://searchfox.org/mozilla-central/rev/9dceacf3d761eb91237108ec438d64099a56f442/ipc/glue/MessageChannel.cpp#2774, https://searchfox.org/mozilla-central/rev/9dceacf3d761eb91237108ec438d64099a56f442/ipc/glue/MessageChannel.cpp#1298. In addition we've got a few places where we pop tasks from the mPending queue, again without checking if IsScheduled(), and don't Clear() the tasks there either: https://searchfox.org/mozilla-central/rev/9dceacf3d761eb91237108ec438d64099a56f442/ipc/glue/MessageChannel.cpp#2710-2714, https://searchfox.org/mozilla-central/rev/9dceacf3d761eb91237108ec438d64099a56f442/ipc/glue/MessageChannel.cpp#1623-1627.

These removed tasks are not Clear()-ed, so if the channel is destroyed after they're removed but before they're Run(), we'll access mChannel to lock mMonitor before checking isInList, and will crash before we notice we've been cancelled. This could be potentially fixed by calling Clear() in more places, but I think it'd be simpler to remove the need for two functions by caching a pointer to mMonitor in the task itself, and locking it to check isInList() before accessing the mChannel member. That way we'll never try to access the channel unless we know that the MessageTask has not been cancelled & removed from mPending.

I'll attach a patch which makes my suggested changes.

Flags: needinfo?(nika)

This simplifies the logic around MessageTask's lifecycle to make
ownership as clear as possible and reduce the number of redundant
checks.

This new change no longer clears the mChannel member when the
MessageTask is disconnected, instead relying on isInList() to check
whether the MessageTask is still in the channel's mPending list. This is
already being automatically managed as the mPending list is modified,
and should avoid potential usage mistakes.

Assignee: nobody → nika

Thanks Nika!

It sounds like this is a general issue with IPC lifetime management and not just a layers shutdown issue, so I'll mark it sec-high.

Status: UNCONFIRMED → NEW
status-firefox91: --- → wontfix
status-firefox92: --- → affected
status-firefox93: --- → affected
status-firefox-esr78: --- → affected
status-firefox-esr91: --- → affected
Ever confirmed: true

Given that we're nearly into RC week for Fx92/91.1esr/78.14esr at this point, I think we should target landing this in the next cycle. Note that ESR78 will require a rebased patch as well.

status-firefox92: affected → wontfix
tracking-firefox93: --- → +
tracking-firefox-esr78: --- → 93+
tracking-firefox-esr91: --- → 93+

(In reply to Ryan VanderMeulen [:RyanVM] from comment #6)

Given that we're nearly into RC week for Fx92/91.1esr/78.14esr at this point, I think we should target landing this in the next cycle. Note that ESR78 will require a rebased patch as well.

This patch might be quite difficult to uplift to ESR78 due to the IPC architecture changes made since then

Comment on attachment 9237084 [details]
Bug 1725335 - Streamline ownership and locking in MessageTask, r=#ipc-reviewers

Security Approval Request

  • How easily could an exploit be constructed based on the patch?: I expect it would be somewhat difficult to create an exploit based on this patch due to the requirement of understanding how the interrupt handling system in MessageChannel works. I don't think that the patch paints a bulls-eye on the problem, though an observant reader could probably find it based on the patch.
  • 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?: all
  • If not all supported branches, which bug introduced the flaw?: None
  • Do you have backports for the affected branches?: Yes
  • If not, how different, hard to create, and risky will they be?: I originally thought this would be difficult to uplift, however it does appear that the patch applies cleanly on release, and with some small tweaks should apply to ESR78. I don't know if it will be as effective there (I haven't memorized all of the IPC changes since then), but I'll attach an ESR78-rebased version of the build.
  • How likely is this patch to cause regressions; how much testing does it need?: I think this should be unlikely to cause regressions, but it is possible that I overlooked something.
Attachment #9237084 - Flags: sec-approval?

This simplifies the logic around MessageTask's lifecycle to make
ownership as clear as possible and reduce the number of redundant
checks.

This new change no longer clears the mChannel member when the
MessageTask is disconnected, instead relying on isInList() to check
whether the MessageTask is still in the channel's mPending list. This is
already being automatically managed as the mPending list is modified,
and should avoid potential usage mistakes.

Comment on attachment 9237084 [details]
Bug 1725335 - Streamline ownership and locking in MessageTask, r=#ipc-reviewers

a=dveditz

Pretty obvious a race is involved from the patch, so maybe better to land this on nightly now and ride the upcoming merge to beta than to wait. Let's wait a couple of weeks on the ESR-78/ESR-91 uplifts, though.

Attachment #9237084 - Flags: sec-approval? → sec-approval+

Streamline ownership and locking in MessageTask, r=ipc-reviewers,mccr8
https://hg.mozilla.org/integration/autoland/rev/de92d70a4e19441e7047639347cd35ce4d11bd1f
https://hg.mozilla.org/mozilla-central/rev/de92d70a4e19

Group: dom-core-security → core-security-release
Status: NEW → RESOLVED
Closed: 3 years ago
status-firefox93: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → 93 Branch
Flags: sec-bounty? → sec-bounty+

As part of a security bug pattern analysis, we are requesting your help with a high level analysis of this bug. It is our hope to develop static analysis (or potentially runtime/dynamic analysis) in the future to identify classes of bugs.

Please visit this google form to reply.

Flags: needinfo?(nika)
Whiteboard: [reporter-external] [client-bounty-form] [verif?] → [reporter-external] [client-bounty-form] [verif?][sec-survey]
Flags: qe-verify+

Please credit to yangkang(@dnpushme) of 360 ATA Team.

Flags: needinfo?(nika)

Are we ready to uplift this to the esr branches?

Flags: needinfo?(nika)

Comment on attachment 9237084 [details]
Bug 1725335 - Streamline ownership and locking in MessageTask, r=#ipc-reviewers

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration:
  • User impact if declined: Potential security vulnerability due to UAF during shutdown of process actors
  • Fix Landed on Version: 93
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): The code hasn't changed much since 91 so the patch should apply cleanly as-is, and an uplift to 78 appeared to work more cleanly than I expected. An uplift to 78 may be a bit more risky due to the larger difference in time between when the patch was written and the original version, and less testing being done on that architecture
  • String or UUID changes made by this patch: None
Flags: needinfo?(nika)
Attachment #9237084 - Flags: approval-mozilla-esr91?

Comment on attachment 9237856 [details]
Bug 1725335 - (ESR78) Streamline ownership and locking in MessageTask

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration:
  • User impact if declined: See above
  • Fix Landed on Version: 93
  • Risk to taking this patch: Medium
  • Why is the change risky/not risky? (and alternatives if risky): See above
  • String or UUID changes made by this patch: None
Attachment #9237856 - Flags: approval-mozilla-esr78?

Comment on attachment 9237084 [details]
Bug 1725335 - Streamline ownership and locking in MessageTask, r=#ipc-reviewers

Approved for 91.2esr and 78.15esr.

Attachment #9237084 - Flags: approval-mozilla-esr91? → approval-mozilla-esr91+
Attachment #9237856 - Flags: approval-mozilla-esr78? → approval-mozilla-esr78+
QA Whiteboard: [qa-triaged]

Hi m.cooolie! I've tried to reproduce this bug using your steps from comment 0. Unfortunately, I was not able to follow the step 3, it seems that ff.test.js is missing from the poc file. Instead, I've tried loading the poc.html on a affected asan Nightly build (20210818155306), via a local HTTP python server, but I didn't encounter any tab crashes.

Could you please help us verify if this issue is fixed on you end with the following Firefox builds:

Flags: needinfo?(m.cooolie)

(In reply to Ciprian Georgiu [:ciprian_georgiu], Release Desktop QA from comment #19)

Hi m.cooolie! I've tried to reproduce this bug using your steps from comment 0. Unfortunately, I was not able to follow the step 3, it seems that ff.test.js is missing from the poc file. Instead, I've tried loading the poc.html on a affected asan Nightly build (20210818155306), via a local HTTP python server, but I didn't encounter any tab crashes.

Could you please help us verify if this issue is fixed on you end with the following Firefox builds:

My test show uaf was not reproduced.

Flags: needinfo?(m.cooolie)

Thanks m.coolie! I'll close this as verified fixed per comment 20.

Status: RESOLVED → VERIFIED
status-firefox93: fixed → verified
status-firefox-esr78: fixed → verified
status-firefox-esr91: fixed → verified
Flags: qe-verify+
Whiteboard: [reporter-external] [client-bounty-form] [verif?][sec-survey] → [reporter-external] [client-bounty-form] [verif?][sec-survey][adv-main93+]
Whiteboard: [reporter-external] [client-bounty-form] [verif?][sec-survey][adv-main93+] → [reporter-external] [client-bounty-form] [verif?][sec-survey][adv-main93+][adv-esr78.15+]
Whiteboard: [reporter-external] [client-bounty-form] [verif?][sec-survey][adv-main93+][adv-esr78.15+] → [reporter-external] [client-bounty-form] [verif?][sec-survey][adv-main93+][adv-esr78.15+][adv-esr91.2+]
Attached file advisory.txt —
Attachment #9243763 - Attachment is obsolete: true
Alias: CVE-2021-38496
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: