1888340 - (CVE-2024-6600) WebGL macOS GLSL Shader Out-Of-Bounds Vulnerability

Status: VERIFIED FIXED

(Core :: Graphics: CanvasWebGL, defect, P1)

Description

[pwn2car]

Attachment: oob.html

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36

Steps to reproduce:

Steps to reproduce:
Operating System: MacOS Sonoma 14.4 [Macbook ARM]

1. python3 -m http.server 9292
2. Open Firefox
3. Open http://localhost:9292/poc.html

Actual results:

=================================================================
==5988==ERROR: AddressSanitizer: BUS on unknown address (pc 0x00018e29dd74 bp 0x000173983120 sp 0x000173982f10 T50)
==5988==The signal is caused by a READ memory access.
==5988==Hint: this fault was caused by a dereference of a high value address (see register values below).  Disassemble the provided pc to learn which register was used.
    #0 0x18e29dd74 in ___chkstk_darwin+0x3c (libsystem_pthread.dylib:arm64+0x1d74)
    #1 0x5e708001e4c0aeac  (<unknown module>)
    #2 0x2e520001e4c0cf94  (<unknown module>)
    #3 0xf7128001e4c0592c  (<unknown module>)
    #4 0x2f318001e4bd75a4  (<unknown module>)
    #5 0xb2260001e4b50c04  (<unknown module>)
    #6 0x60238001e4b47c18  (<unknown module>)
    #7 0x7a588001e4b47694  (<unknown module>)
    #8 0xd588001e4b6eda0  (<unknown module>)
    #9 0x8d6a0001012f2c88  (<unknown module>)
    #10 0x18e0f23e4 in _dispatch_client_callout+0x10 (libdispatch.dylib:arm64+0x43e4)
    #11 0x1a4a80018e1018d4  (<unknown module>)
    #12 0xa5058001012f2f0c  (<unknown module>)
    #13 0x1e4ae65d8 in glFlush_ExecThread+0x1c (GLEngine:arm64+0x4f5d8)
    #14 0x9e24800129987b80  (<unknown module>)
    #15 0x12d140198 in bool (*mozilla::MethodDispatcher<mozilla::WebGLMethodDispatcher, 26ul, void (mozilla::HostWebGLContext::*)(), &mozilla::HostWebGLContext::DidRefresh()>::DispatchCommandFuncById<mozilla::HostWebGLContext>(unsigned long))(mozilla::HostWebGLContext&, mozilla::webgl::RangeConsumerView&)::'lambda'(mozilla::HostWebGLContext&, mozilla::webgl::RangeConsumerView&)::__invoke(mozilla::HostWebGLContext&, mozilla::webgl::RangeConsumerView&)+0x4c (XUL:arm64+0x6304198)
    #16 0x12d0ea7e4 in mozilla::dom::WebGLParent::RecvDispatchCommands(mozilla::ipc::BigBuffer&&, unsigned long long)+0x570 (XUL:arm64+0x62ae7e4)
    #17 0x12d202780 in mozilla::dom::PWebGLParent::OnMessageReceived(IPC::Message const&)+0xbe4 (XUL:arm64+0x63c6780)
    #18 0x12a120dac in mozilla::gfx::PCanvasManagerParent::OnMessageReceived(IPC::Message const&)+0x344 (XUL:arm64+0x32e4dac)
    #19 0x128f712a8 in mozilla::ipc::MessageChannel::DispatchAsyncMessage(mozilla::ipc::ActorLifecycleProxy*, IPC::Message const&)+0x14c (XUL:arm64+0x21352a8)
    #20 0x128f6e78c in mozilla::ipc::MessageChannel::DispatchMessage(mozilla::ipc::ActorLifecycleProxy*, mozilla::UniquePtr<IPC::Message, mozilla::DefaultDelete<IPC::Message>>)+0x41c (XUL:arm64+0x213278c)
    #21 0x128f6f548 in mozilla::ipc::MessageChannel::RunMessage(mozilla::ipc::ActorLifecycleProxy*, mozilla::ipc::MessageChannel::MessageTask&)+0x2b4 (XUL:arm64+0x2133548)
    #22 0x128f6ff90 in mozilla::ipc::MessageChannel::MessageTask::Run()+0x14c (XUL:arm64+0x2133f90)
    #23 0x127a6afb4 in nsThread::ProcessNextEvent(bool, bool*)+0xd8c (XUL:arm64+0xc2efb4)
    #24 0x127a7730c in NS_ProcessNextEvent(nsIThread*, bool)+0x114 (XUL:arm64+0xc3b30c)
    #25 0x128f7a49c in mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*)+0x264 (XUL:arm64+0x213e49c)
    #26 0x128e6e3bc in MessageLoop::Run()+0x1c4 (XUL:arm64+0x20323bc)
    #27 0x127a6381c in nsThread::ThreadFunc(void*)+0x290 (XUL:arm64+0xc2781c)
    #28 0x1041eeb08 in _pt_root+0x384 (libnss3.dylib:arm64+0x3cab08)
    #29 0x1012f119c in asan_thread_start(void*)+0x3c (libclang_rt.asan_osx_dynamic.dylib:arm64+0x4d19c)
    #30 0x18e2a2f90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64+0x6f90)
    #31 0xef6180018e29dd30  (<unknown module>)

==5988==Register values:
 x[0] = 0x00006300000c0ce0   x[1] = 0x000000000008dac0   x[2] = 0x0000606000fdab40   x[3] = 0x00006270001e3eb0
 x[4] = 0x00000001f647b010   x[5] = 0x0000000000000000   x[6] = 0x00006270001e3320   x[7] = 0x00006270001e4178
 x[8] = 0x000000000008dac0   x[9] = 0x000000000008dac0  x[10] = 0x00000001738f5450  x[11] = 0x0000000173904000
x[12] = 0x0200000102000998  x[13] = 0x0000615000253d80  x[14] = 0x01000001f784a3ed  x[15] = 0x00000001f784a3e8
x[16] = 0x000000018e29dd38  x[17] = 0x00000001ffea56b8  x[18] = 0x0000000000000000  x[19] = 0x0000000173982f10
x[20] = 0x0000000000000000  x[21] = 0x00006270001e3320  x[22] = 0x00006270001e3100  x[23] = 0x00006270001e4178
x[24] = 0x00000000fffffffe  x[25] = 0x000061e0004f0880  x[26] = 0x0000631010f90800  x[27] = 0x0000631010f90800
x[28] = 0x0000000000000000     fp = 0x0000000173983120     lr = 0x00000001e49a2cc4     sp = 0x0000000173982f10
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: BUS (libsystem_pthread.dylib:arm64+0x1d74) in ___chkstk_darwin+0x3c
Thread T50 created by T0 here:
    #0 0x1012ebda0 in pthread_create+0x58 (libclang_rt.asan_osx_dynamic.dylib:arm64+0x47da0)
    #1 0x1041dedf8 in _PR_CreateThread+0x448 (libnss3.dylib:arm64+0x3badf8)
    #2 0x127a661b8 in nsThread::Init(nsTSubstring<char> const&)+0x17c (XUL:arm64+0xc2a1b8)
    #3 0x127a75230 in nsThreadManager::NewNamedThread(nsTSubstring<char> const&, nsIThreadManager::ThreadCreationOptions, nsIThread**)+0x2b0 (XUL:arm64+0xc39230)
    #4 0x127a82af8 in NS_NewNamedThread(nsTSubstring<char> const&, nsIThread**, already_AddRefed<nsIRunnable>, nsIThreadManager::ThreadCreationOptions)+0x148 (XUL:arm64+0xc46af8)
    #5 0x12a0e4cbc in mozilla::gfx::CanvasRenderThread::Start()+0x4bc (XUL:arm64+0x32a8cbc)
    #6 0x129f24e7c in gfxPlatform::Init()+0x19e4 (XUL:arm64+0x30e8e7c)
    #7 0x129f2334c in gfxPlatform::GetPlatform()+0x2c (XUL:arm64+0x30e734c)
    #8 0x130b8a620 in mozilla::widget::GfxInfoBase::GetContentBackend(nsTSubstring<char16_t>&)+0xac (XUL:arm64+0x9d4e620)
    #9 0x127ab7084 in _NS_InvokeByIndex+0x5c (XUL:arm64+0xc7b084)
    #10 0x12927f93c in XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode)+0x27f0 (XUL:arm64+0x244393c)
    #11 0x129285780 in XPC_WN_GetterSetter(JSContext*, unsigned int, JS::Value*)+0x594 (XUL:arm64+0x2449780)
    #12 0x1343e1da8 in js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason)+0x86c (XUL:arm64+0xd5a5da8)
    #13 0x1343e3878 in js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>, js::CallReason)+0x1dc (XUL:arm64+0xd5a7878)
    #14 0x1343e52b0 in js::CallGetter(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, JS::MutableHandle<JS::Value>)+0x234 (XUL:arm64+0xd5a92b0)
    #15 0x1347a1ec8 in js::NativeGetProperty(JSContext*, JS::Handle<js::NativeObject*>, JS::Handle<JS::Value>, JS::Handle<JS::PropertyKey>, JS::MutableHandle<JS::Value>)+0x141c (XUL:arm64+0xd965ec8)
    #16 0x1343fc1e8 in js::Interpret(JSContext*, js::RunState&)+0x12534 (XUL:arm64+0xd5c01e8)
    #17 0x1343e0d10 in js::RunScript(JSContext*, js::RunState&)+0x4d4 (XUL:arm64+0xd5a4d10)
    #18 0x1343e1eb4 in js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason)+0x978 (XUL:arm64+0xd5a5eb4)
    #19 0x1343e3878 in js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>, js::CallReason)+0x1dc (XUL:arm64+0xd5a7878)
    #20 0x1343e52b0 in js::CallGetter(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, JS::MutableHandle<JS::Value>)+0x234 (XUL:arm64+0xd5a92b0)
    #21 0x1347a1ec8 in js::NativeGetProperty(JSContext*, JS::Handle<js::NativeObject*>, JS::Handle<JS::Value>, JS::Handle<JS::PropertyKey>, JS::MutableHandle<JS::Value>)+0x141c (XUL:arm64+0xd965ec8)
    #22 0x134416e40 in js::GetProperty(JSContext*, JS::Handle<JS::Value>, JS::Handle<js::PropertyName*>, JS::MutableHandle<JS::Value>)+0x82c (XUL:arm64+0xd5dae40)
    #23 0x1343ec78c in js::Interpret(JSContext*, js::RunState&)+0x2ad8 (XUL:arm64+0xd5b078c)
    #24 0x1343e0d10 in js::RunScript(JSContext*, js::RunState&)+0x4d4 (XUL:arm64+0xd5a4d10)
    #25 0x1343e1eb4 in js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason)+0x978 (XUL:arm64+0xd5a5eb4)
    #26 0x1343e3878 in js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>, js::CallReason)+0x1dc (XUL:arm64+0xd5a7878)
    #27 0x1345bc67c in JS_CallFunctionValue(JSContext*, JS::Handle<JSObject*>, JS::Handle<JS::Value>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>)+0x480 (XUL:arm64+0xd78067c)
    #28 0x129270568 in nsXPCWrappedJS::CallMethod(unsigned short, nsXPTMethodInfo const*, nsXPTCMiniVariant*)+0x11b4 (XUL:arm64+0x2434568)
    #29 0x127ab8b68 in PrepareAndDispatch+0x970 (XUL:arm64+0xc7cb68)
    #30 0x127ab70d4 in SharedStub+0x3c (XUL:arm64+0xc7b0d4)
    #31 0x1279f69c4 in NS_CreateServicesFromCategory(char const*, nsISupports*, char const*, char16_t const*)+0xa28 (XUL:arm64+0xbba9c4)
    #32 0x1341de7e8 in nsXREDirProvider::DoStartup()+0x4a8 (XUL:arm64+0xd3a27e8)
    #33 0x1341c1ad0 in XREMain::XRE_mainRun()+0xe2c (XUL:arm64+0xd385ad0)
    #34 0x1341c40c0 in XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&)+0xcb0 (XUL:arm64+0xd3880c0)
    #35 0x1341c5170 in XRE_main(int, char**, mozilla::BootstrapConfig const&)+0x168 (XUL:arm64+0xd389170)
    #36 0x100881184 in main+0x6f8 (firefox:arm64+0x100001184)
    #37 0x18df1a0dc  (<unknown module>)
    #38 0xa3dfffffffffffc  (<unknown module>)

==5988==ABORTING
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.

Actual results:

.

Expected results:

.

Comment 1

[Jim Mathies [:jimm]]

Externally reported, no sec rating yet.

Comment 2

[pwn2car]

This appears to be something wrong with the patch for CVE-2023-29531 updated to MacOS Sonoma 14.4.

Comment 3

[Andrew McCreight [:mccr8]]

I haven't investigated the validity of this report, but an out of bounds issue sounds like sec-high to me, so I'll rate it.

Comment 4

[Kelsey Gilbert [:jgilbert]]

The POC is calling drawElements(POINTS, count=2, UNSIGNED_BYTE, offset=0), with an index buffer of:

ibd = new Int16Array([120231])
-> Int16Array [ -10841 ]

ibd8 = new Uint8Array(ibd.buffer)
-> Uint8Array [ 167, 213 ]

Thus we're drawing two points, as if for (vertex_id of [167, 213]).
There are no vertex arrays enabled, but there's also no vertex shader input attribs.
This is happening on Mac, which is one of the places that needs fake-attrib-0 emulation.
I don't remember whether we do fake-attrib-0 emulation if no attribs are needed, but we probably need to.

---

The vertex shader is trivial:

void main(){}

There is this suspicious GLSL in the fragment shader:

void main( void )
{
  const int numColors = 9000;
  vec3 colors[numColors];
[...]
  vec3 color = mix( colors[0], colors[1], pow(rand,5.0) );     // The only use of the `colors` array.

---

This is reminiscent of the problematic GLSL in bug 1773874.

      int pad[0x40000];
      gl_FragColor += vec4(float(pad[42]));

---

In response to bug 1773874, we added this limit to ANGLE:

https://searchfox.org/mozilla-central/source/gfx/angle/checkout/src/compiler/translator/ValidateTypeSizeLimitations.cpp#28-29

constexpr size_t kMaxVariableSizeInBytes        = static_cast<size_t>(2) * 1024 * 1024 * 1024;
constexpr size_t kMaxPrivateVariableSizeInBytes = static_cast<size_t>(1) * 1024 * 1024;

---

Since then, Google has further reduced this limit, from 1MiB to 64KiB:
https://github.com/google/angle/blob/9ce8d3ba042d42f0e31d2a261ed4d4b9b9f7668a/src/compiler/translator/ValidateTypeSizeLimitations.cpp#L29-L31

constexpr size_t kMaxVariableSizeInBytes             = static_cast<size_t>(2) * 1024 * 1024 * 1024;
constexpr size_t kMaxPrivateVariableSizeInBytes      = static_cast<size_t>(64) * 1024;
constexpr size_t kMaxTotalPrivateVariableSizeInBytes = static_cast<size_t>(16) * 1024 * 1024;

---

However, the array in the POC in our bug here is int[9000], which is only 36KB.
In bug 1843782, we considered restricting kMaxPrivateVariableSizeInBytes to 16KiB on Mesa, but decided to use a different mitigation. We could revive that approach if it works for mitigation in this case.
In bug 1794292, we always initialize gl_PointSize on Mac, though it looks like it probably initializes it to 0, which is still invalid, and may be still causing issues.
In bug 1803715 , we plan to forbid draw calls of POINTS where gl_PointSize was not written. That would likely invalidate this POC, but it's possible that it could be trivially amended to draw again.

Priority here is to land bug 1803715, and also for me to try to repro this on my intel mac, so that I can investigate our other mitigations without playing guessing-games or whack-a-mole.

Comment 5

[Kelsey Gilbert [:jgilbert]]

I can repro this crash instantly on my Intel MacBook Pro (15-inch, 2019):

• 2.4 GHz 8-Core Intel Core i9
• Intel UHD Graphics 630 1536 MB
• macOS Sonoma Version 14.1.1 (23B81)

Amending the testcase to write gl_PointSize = 1.0f; (or = 0.0f;!) causes it not to crash anymore, and deleting the write to PointSize causes the testcase to resume instantly crashing.

Comment 6

[Kelsey Gilbert [:jgilbert]]

Oops, false alarm!
That was because the N.Nf syntax for floats didn't exist until essl300, so the shader was failing to compile, causing the draw to fail, preventing the crash.
However, indeed setting numColors to 90 prevents the crash. I'll bisect the actual value, but it sounds like we need to prevent these large arrays, as in bug 1773874.

Comment 7

[Kelsey Gilbert [:jgilbert]]

  //bad const int numColors = 9000;
  //ok const int numColors = 900;
  //ok const int numColors = 4000;
  //ok const int numColors = 7000;
  //ok const int numColors = 8000;
  //bad const int numColors = 8500;
  //bad const int numColors = 8250;
  //ok const int numColors = 8150;
  //bad const int numColors = 8200;
  //ok const int numColors = 8192;
  //bad const int numColors = 8193;
  const int numColors = 8192;

"8192 ints ought to be enough for anyone!" -Apple driver team, probably :)

Comment 8

[Daniel Veditz [:dveditz]]

I assume this would affect ESR-115 as well

I can repro this crash instantly on my Intel MacBook Pro (15-inch, 2019):

Is that a nightly or opt build? I haven't tried ASAN but I can't reproduce on my M3 Macbook Pro (2023), Sonoma 14.5 in a Nightly or Release build.

Comment 9

[Daniel Veditz [:dveditz]]

Sorry for the burst of bugspam: filter on tinkling-glitter-filtrate
Adding reporter-external keyword to security bugs found by non-employees for accounting reasons

Comment 10

[Kelsey Gilbert [:jgilbert]]

Attachment: Bug 1888340 - [angle] Cherry-pick to "Add GLSL variable byte size limits to ShBuiltInResources."

Comment 11

[Kelsey Gilbert [:jgilbert]]

Attachment: Bug 1888340 - Add prefs and platform limits for MaxPrivateVariableSizeInBytes.

Comment 12

[Kelsey Gilbert [:jgilbert]]

(In reply to Daniel Veditz [:dveditz] from comment #8)

I assume this would affect ESR-115 as well

I can repro this crash instantly on my Intel MacBook Pro (15-inch, 2019):

Is that a nightly or opt build? I haven't tried ASAN but I can't reproduce on my M3 Macbook Pro (2023), Sonoma 14.5 in a Nightly or Release build.

Sorry, nightly. I must have lost the comment I was going to post about this.
This only affects Intel CPU macs on macos.

Comment 13

[Kelsey Gilbert [:jgilbert]]

Comment on attachment 9405974 [details]
Bug 1888340 - [angle] Cherry-pick to "Add GLSL variable byte size limits to ShBuiltInResources."

Security Approval Request

• How easily could an exploit be constructed based on the patch?: Very hard.
  It's moderate difficulty to come up with a PoC of a crash from the patch, but there's no established path from this PoC to an exploit. (this should probably be sec-moderate)
• 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 branches (beta, release, and/or ESR) are affected by this flaw, and do the release status flags reflect this affected/unaffected state correctly?: all
• 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?: Relatively easy, but not trivial.
• How likely is this patch to cause regressions; how much testing does it need?: Unlikely, but not extremely unlikely, but any issue we run into later will probably not be viable for us to find with internal testing.
  However, this is a pref, and it will be easy to fix it if needed.
• Is the patch ready to land after security approval is given?: Yes
• Is Android affected?: No

Comment 14

[Kelsey Gilbert [:jgilbert]]

Comment on attachment 9405975 [details]
Bug 1888340 - Add prefs and platform limits for MaxPrivateVariableSizeInBytes.

Security Approval Request

• How easily could an exploit be constructed based on the patch?: (see sec-approval request for other patch)
• Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?: Yes
• Which branches (beta, release, and/or ESR) are affected by this flaw, and do the release status flags reflect this affected/unaffected state correctly?:
• 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?:
• How likely is this patch to cause regressions; how much testing does it need?:
• Is the patch ready to land after security approval is given?: Yes
• Is Android affected?: Yes

Comment 15

[Kelsey Gilbert [:jgilbert]]

I believe that ___chkstk_darwin is the OS-level stack-overflow protection kicking in, and that because of this defense-in-depth, we are likely (but not certainly) safe here. => sec-moderate

Comment 16

[Daniel Veditz [:dveditz]]

Comment on attachment 9405974 [details]
Bug 1888340 - [angle] Cherry-pick to "Add GLSL variable byte size limits to ShBuiltInResources."

sec-approval+ = dveditz.

Because the Chromium bug is public we'll want to make sure this lands on Beta and ESR.

Comment 17

[Kelsey Gilbert [:jgilbert]]

Attachment: Bug 1888340 - [angle] Cherry-pick to "Add GLSL variable byte size limits to ShBuiltInResources."

Original Revision: https://phabricator.services.mozilla.com/D212854

Comment 18

[Kelsey Gilbert [:jgilbert]]

Attachment: Bug 1888340 - Add prefs and platform limits for MaxPrivateVariableSizeInBytes.

Original Revision: https://phabricator.services.mozilla.com/D212855

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6ff538ec0caf
[angle] Cherry-pick to "Add GLSL variable byte size limits to ShBuiltInResources." r=gfx-reviewers,lsalzman
https://hg.mozilla.org/integration/autoland/rev/279dcaaaa3e0
Add prefs and platform limits for MaxPrivateVariableSizeInBytes. r=gfx-reviewers,lsalzman

Comment 20

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

https://hg.mozilla.org/mozilla-central/rev/6ff538ec0caf
https://hg.mozilla.org/mozilla-central/rev/279dcaaaa3e0

Comment 21

[Phabricator Automation]

beta Uplift Approval Request

• User impact if declined: sec-moderate, some very rare webgl content would reliably crash on mac
• Code covered by automated testing: no
• Fix verified in Nightly: no
• Needs manual QE test: no
• Steps to reproduce for manual QE testing: Testcase in bug, load on mac, no crash => success
• Risk associated with taking this patch: low
• Explanation of risk level: If it builds, it's unlikely to break, and it's very unlikely that we would run into issues that we don't quickly discover on Nightly.
• String changes made/needed: none
• Is Android affected?: no

Comment 22

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/400ed21f79d9
https://hg.mozilla.org/releases/mozilla-beta/rev/3f2595de6b1e

Comment 23

[Catalin Sasca, Desktop Test Engineering [:csasca]]

Reproduced the issue on Firefox 126.0a1 (2024-03-28) on macOS 14.5 by using the STR provided in Comment 0, on a Intel Macbook Pro 2019.

The issue is fixed on Firefox 128.0b9 (treeherder build) and Firefox 129.0a1 (2024-06-27) on the same system. Note that on Arm systems there was a freeze of ~3-4 seconds but no crash, and that was fixed as well on the latest builds.

Will check on ESR as well when/if the fix will be implemented.

Comment 24

[Jim Mathies [:jimm]]

FYI looking for a patch for esr 115.

Comment 25

[Kelsey Gilbert [:jgilbert]]

Attachment: Bug 1888340 - [angle] Cherry-pick to "Add GLSL variable byte size limits to ShBuiltInResources."

Comment 26

[Kelsey Gilbert [:jgilbert]]

Attachment: Bug 1888340 - Add prefs and platform limits for MaxPrivateVariableSizeInBytes.

Comment 27

[Phabricator Automation]

esr115 Uplift Approval Request

• User impact if declined: sec-moderate, some very rare webgl content would reliably crash on mac
• Code covered by automated testing: no
• Fix verified in Nightly: yes
• Needs manual QE test: no
• Steps to reproduce for manual QE testing: Testcase in bug, load on mac, no crash => success
• Risk associated with taking this patch: low
• Explanation of risk level: If it builds, it's unlikely to break, and it's very unlikely that we would run into issues that we don't quickly discover on Nightly.
• String changes made/needed: none
• Is Android affected?: no

Comment 28

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr115/rev/cfc154018788
https://hg.mozilla.org/releases/mozilla-esr115/rev/b7e26a68acf9

Comment 29

[Catalin Sasca, Desktop Test Engineering [:csasca]]

Verified that the issue is fixed on ESR 115.13.0-build2 as well.

Comment 30

[Simon Friedberger (:simonf)]

Attachment: advisory.txt