Bugzilla

We currently do not understand how the exploit works. We have [a check in `CompositorBridgeParent::AllocPWebGPUParent`](https://hg.mozilla.org/releases/mozilla-release/file/0f0ba6e8029d8148743c4aa50c2be4c4c643f8a4/gfx/layers/ipc/CompositorBridgeParent.cpp#l1293) which checks `mOptions.UseWebGPU()`:

```cpp
  // We should only ever get this if WebGPU is enabled in this compositor.
  MOZ_RELEASE_ASSERT(mOptions.UseWebGPU());
```

The only way to influence `mOptions` is from the [`CompositorBridgeParent` constructor](https://hg.mozilla.org/releases/mozilla-release/file/0f0ba6e8029d8148743c4aa50c2be4c4c643f8a4/gfx/layers/ipc/CompositorBridgeParent.cpp#l283), which is only called from two places:
 - [In `CreateSameProcessWidgetCompositorBridge`](https://hg.mozilla.org/releases/mozilla-release/file/0f0ba6e8029d8148743c4aa50c2be4c4c643f8a4/gfx/layers/ipc/CompositorManagerParent.cpp#l112), which is not callable from content
 - [In `CompositorManagerParent::AllocPCompositorBridgeParent`](https://hg.mozilla.org/releases/mozilla-release/file/0f0ba6e8029d8148743c4aa50c2be4c4c643f8a4/gfx/layers/ipc/CompositorManagerParent.cpp#l232) which is triggered by a message from content.

But the call in `CompositorManagerParent::AllocPCompositorBridgeParent` is in the `CompositorBridgeOptions::TWidgetCompositorOptions` branch, which has the following check:

```cpp
      gfx::GPUParent* gpu = gfx::GPUParent::GetSingleton();
      if (NS_WARN_IF(!gpu || OtherPid() != gpu->OtherPid())) {
        MOZ_ASSERT_UNREACHABLE("Child cannot create widget compositor!");
        break;
      }
```

So if this method is called in response to a message from the content process, the `OtherPid() != gpu->OtherPid()` check should fail, and we should bail out.

So I don't know how content can cause the creation of a `CompositorBridgeParent` whose `mOptions` has `UseWebGPU() == true`, unless the WebGPU pref is enabled.

We currently do not understand how the exploit works in Firefox 97. We have [a check in `CompositorBridgeParent::AllocPWebGPUParent`](https://hg.mozilla.org/releases/mozilla-release/file/0f0ba6e8029d8148743c4aa50c2be4c4c643f8a4/gfx/layers/ipc/CompositorBridgeParent.cpp#l1293) which checks `mOptions.UseWebGPU()`:

```cpp
  // We should only ever get this if WebGPU is enabled in this compositor.
  MOZ_RELEASE_ASSERT(mOptions.UseWebGPU());
```

The only way to influence `mOptions` is from the [`CompositorBridgeParent` constructor](https://hg.mozilla.org/releases/mozilla-release/file/0f0ba6e8029d8148743c4aa50c2be4c4c643f8a4/gfx/layers/ipc/CompositorBridgeParent.cpp#l283), which is only called from two places:
 - [In `CreateSameProcessWidgetCompositorBridge`](https://hg.mozilla.org/releases/mozilla-release/file/0f0ba6e8029d8148743c4aa50c2be4c4c643f8a4/gfx/layers/ipc/CompositorManagerParent.cpp#l112), which is not callable from content
 - [In `CompositorManagerParent::AllocPCompositorBridgeParent`](https://hg.mozilla.org/releases/mozilla-release/file/0f0ba6e8029d8148743c4aa50c2be4c4c643f8a4/gfx/layers/ipc/CompositorManagerParent.cpp#l232) which is triggered by a message from content.

But the call in `CompositorManagerParent::AllocPCompositorBridgeParent` is in the `CompositorBridgeOptions::TWidgetCompositorOptions` branch, which has the following check:

```cpp
      gfx::GPUParent* gpu = gfx::GPUParent::GetSingleton();
      if (NS_WARN_IF(!gpu || OtherPid() != gpu->OtherPid())) {
        MOZ_ASSERT_UNREACHABLE("Child cannot create widget compositor!");
        break;
      }
```

So if this method is called in response to a message from the content process, the `OtherPid() != gpu->OtherPid()` check should fail, and we should bail out.

So I don't know how content can cause the creation of a `CompositorBridgeParent` whose `mOptions` has `UseWebGPU() == true`, unless the WebGPU pref is enabled.

We currently do not understand how the exploit works in Firefox 97 if the WebGPU pref is disabled. We have [a check in `CompositorBridgeParent::AllocPWebGPUParent`](https://hg.mozilla.org/releases/mozilla-release/file/0f0ba6e8029d8148743c4aa50c2be4c4c643f8a4/gfx/layers/ipc/CompositorBridgeParent.cpp#l1293) which checks `mOptions.UseWebGPU()`:

```cpp
  // We should only ever get this if WebGPU is enabled in this compositor.
  MOZ_RELEASE_ASSERT(mOptions.UseWebGPU());
```

The only way to influence `mOptions` is from the [`CompositorBridgeParent` constructor](https://hg.mozilla.org/releases/mozilla-release/file/0f0ba6e8029d8148743c4aa50c2be4c4c643f8a4/gfx/layers/ipc/CompositorBridgeParent.cpp#l283), which is only called from two places:
 - [In `CreateSameProcessWidgetCompositorBridge`](https://hg.mozilla.org/releases/mozilla-release/file/0f0ba6e8029d8148743c4aa50c2be4c4c643f8a4/gfx/layers/ipc/CompositorManagerParent.cpp#l112), which is not callable from content
 - [In `CompositorManagerParent::AllocPCompositorBridgeParent`](https://hg.mozilla.org/releases/mozilla-release/file/0f0ba6e8029d8148743c4aa50c2be4c4c643f8a4/gfx/layers/ipc/CompositorManagerParent.cpp#l232) which is triggered by a message from content.

But the call in `CompositorManagerParent::AllocPCompositorBridgeParent` is in the `CompositorBridgeOptions::TWidgetCompositorOptions` branch, which has the following check:

```cpp
      gfx::GPUParent* gpu = gfx::GPUParent::GetSingleton();
      if (NS_WARN_IF(!gpu || OtherPid() != gpu->OtherPid())) {
        MOZ_ASSERT_UNREACHABLE("Child cannot create widget compositor!");
        break;
      }
```

So if this method is called in response to a message from the content process, the `OtherPid() != gpu->OtherPid()` check should fail, and we should bail out.

So I don't know how content can cause the creation of a `CompositorBridgeParent` whose `mOptions` has `UseWebGPU() == true`, unless the WebGPU pref is enabled.