Firefox WebGL DrawElementsInstanced Heap-Buffer-Overflow Possibly leading to Sandbox Escape Vulnerability (Mesa VM driver / Linux)
Categories
(Core :: Graphics: CanvasWebGL, defect, P1)
Tracking
()
People
(Reporter: d4ni31, Assigned: ahale)
References
Details
(6 keywords, Whiteboard: [disclosure deadline 2023-12-19][adv-main121+][adv-esr115.6+])
Attachments
(11 files, 4 obsolete files)
|
2.51 KB,
text/html
|
Details | |
|
43.98 KB,
application/json
|
Details | |
|
27.12 KB,
text/plain
|
Details | |
|
48 bytes,
text/x-phabricator-request
|
tjr
:
sec-approval+
|
Details | Review |
|
1.23 KB,
patch
|
Details | Diff | Splinter Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
RyanVM
:
approval-mozilla-beta+
|
Details | Review |
|
48 bytes,
text/x-phabricator-request
|
RyanVM
:
approval-mozilla-esr115+
|
Details | Review |
|
341 bytes,
text/plain
|
Details | |
|
69.34 KB,
application/json
|
Details | |
|
70.76 KB,
application/json
|
Details |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36
Steps to reproduce:
Title
- Firefox WebGL DrawElementsInstanced Heap-Buffer-Overflow Vulnerability
Summary
- A Heap-Buffer-Overflow vulnerability exists in the WebGL DrawElementsInstanced
- The browser process crashes when triggering this bug.
Test environment
- Product : Firefox Stable & Firefox ASan Build Opt
- VM : Virtualbox 7.0.8
- GUEST OS : Ubuntu Desktop 23.04
ASan
=================================================================
==11034==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6310051f36c8 at pc 0x5569d5ba3671 bp 0x7f3dd59f9880 sp 0x7f3dd59f9040
READ of size 84704 at 0x6310051f36c8 thread T36
#0 0x5569d5ba3670 in memcpy /builds/worker/fetches/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:875:5
#1 0x7f3d98459ee4 (/usr/lib/x86_64-linux-gnu/dri/vmwgfx_dri.so+0xa59ee4) (BuildId: 60cea14709f13d122c75908469400dbfeb094a60)
#2 0x7f3d9846a4f4 (/usr/lib/x86_64-linux-gnu/dri/vmwgfx_dri.so+0xa6a4f4) (BuildId: 60cea14709f13d122c75908469400dbfeb094a60)
#3 0x7f3d98445dfc (/usr/lib/x86_64-linux-gnu/dri/vmwgfx_dri.so+0xa45dfc) (BuildId: 60cea14709f13d122c75908469400dbfeb094a60)
#4 0x7f3d98449fba (/usr/lib/x86_64-linux-gnu/dri/vmwgfx_dri.so+0xa49fba) (BuildId: 60cea14709f13d122c75908469400dbfeb094a60)
#5 0x7f3d98446612 (/usr/lib/x86_64-linux-gnu/dri/vmwgfx_dri.so+0xa46612) (BuildId: 60cea14709f13d122c75908469400dbfeb094a60)
#6 0x7f3d984466cf (/usr/lib/x86_64-linux-gnu/dri/vmwgfx_dri.so+0xa466cf) (BuildId: 60cea14709f13d122c75908469400dbfeb094a60)
#7 0x7f3d98446733 (/usr/lib/x86_64-linux-gnu/dri/vmwgfx_dri.so+0xa46733) (BuildId: 60cea14709f13d122c75908469400dbfeb094a60)
#8 0x7f3d9843a24c (/usr/lib/x86_64-linux-gnu/dri/vmwgfx_dri.so+0xa3a24c) (BuildId: 60cea14709f13d122c75908469400dbfeb094a60)
#9 0x7f3d97cf20aa (/usr/lib/x86_64-linux-gnu/dri/vmwgfx_dri.so+0x2f20aa) (BuildId: 60cea14709f13d122c75908469400dbfeb094a60)
#10 0x7f3d97cf3885 (/usr/lib/x86_64-linux-gnu/dri/vmwgfx_dri.so+0x2f3885) (BuildId: 60cea14709f13d122c75908469400dbfeb094a60)
#11 0x7f3dfc619bfb in raw_fDrawElements /builds/worker/checkouts/gecko/gfx/gl/GLContext.h:1076:5
#12 0x7f3dfc619bfb in mozilla::gl::GLContext::fDrawElements(unsigned int, int, unsigned int, void const*) /builds/worker/checkouts/gecko/gfx/gl/GLContext.h:1090:5
#13 0x7f3dfc6193ab in mozilla::WebGLContext::DrawElementsInstanced(unsigned int, int, unsigned int, long, int) /builds/worker/checkouts/gecko/dom/canvas/WebGLContextDraw.cpp:1057:15
#14 0x7f3dfc6f17f0 in DrawElementsInstanced /builds/worker/checkouts/gecko/dom/canvas/HostWebGLContext.h:755:15
#15 0x7f3dfc6f17f0 in auto bool mozilla::MethodDispatcher<mozilla::WebGLMethodDispatcher, 101ul, void (mozilla::HostWebGLContext::*)(unsigned int, int, unsigned int, long, int) const, &mozilla::HostWebGLContext::DrawElementsInstanced(unsigned int, int, unsigned int, long, int) const>::DispatchCommand<mozilla::HostWebGLContext>(mozilla::HostWebGLContext&, unsigned long, mozilla::webgl::RangeConsumerView&)::'lambda'(auto&...)::operator()<unsigned int, int, unsigned int, long, int>(auto&...) const /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:253:13
#16 0x7f3dfc69c9c5 in __invoke_impl<bool, (lambda at /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:245:11), unsigned int &, int &, unsigned int &, long &, int &> /builds/worker/fetches/sysroot-x86_64-linux-gnu/usr/lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/invoke.h:60:14
#17 0x7f3dfc69c9c5 in __invoke<(lambda at /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:245:11), unsigned int &, int &, unsigned int &, long &, int &> /builds/worker/fetches/sysroot-x86_64-linux-gnu/usr/lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/bits/invoke.h:95:14
#18 0x7f3dfc69c9c5 in __apply_impl<(lambda at /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:245:11), std::tuple<unsigned int, int, unsigned int, long, int> &, 0UL, 1UL, 2UL, 3UL, 4UL> /builds/worker/fetches/sysroot-x86_64-linux-gnu/usr/lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/tuple:1678:14
#19 0x7f3dfc69c9c5 in apply<(lambda at /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:245:11), std::tuple<unsigned int, int, unsigned int, long, int> &> /builds/worker/fetches/sysroot-x86_64-linux-gnu/usr/lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/tuple:1687:14
#20 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:244:14
#21 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#22 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#23 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#24 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#25 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#26 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#27 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#28 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#29 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#30 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#31 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#32 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#33 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#34 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#35 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#36 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#37 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#38 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#39 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#40 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#41 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#42 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#43 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#44 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#45 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#46 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#47 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#48 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#49 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#50 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#51 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#52 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#53 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#54 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#55 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#56 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#57 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#58 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#59 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#60 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#61 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#62 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#63 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#64 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#65 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#66 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#67 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#68 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#69 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#70 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#71 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#72 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#73 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#74 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#75 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#76 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#77 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#78 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#79 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#80 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#81 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#82 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#83 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#84 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#85 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#86 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#87 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#88 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#89 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#90 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#91 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#92 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#93 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#94 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#95 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#96 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#97 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#98 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#99 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#100 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#101 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#102 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#103 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#104 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#105 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#106 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#107 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#108 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#109 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#110 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#111 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#112 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#113 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#114 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#115 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#116 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#117 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#118 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#119 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#120 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#121 0x7f3dfc69c9c5 in DispatchCommand<mozilla::HostWebGLContext> /builds/worker/checkouts/gecko/dom/canvas/WebGLCommandQueue.h:258:12
#122 0x7f3dfc69c9c5 in mozilla::dom::WebGLParent::RecvDispatchCommands(mozilla::ipc::BigBuffer&&, unsigned long) /builds/worker/checkouts/gecko/dom/canvas/WebGLParent.cpp:62:21
#123 0x7f3dfc7c811a in mozilla::dom::PWebGLParent::OnMessageReceived(IPC::Message const&) /builds/worker/workspace/obj-build/ipc/ipdl/PWebGLParent.cpp:229:79
#124 0x7f3df8f9ff94 in mozilla::gfx::PCanvasManagerParent::OnMessageReceived(IPC::Message const&) /builds/worker/workspace/obj-build/ipc/ipdl/PCanvasManagerParent.cpp:214:32
#125 0x7f3df7a6141d in mozilla::ipc::MessageChannel::DispatchAsyncMessage(mozilla::ipc::ActorLifecycleProxy*, IPC::Message const&) /builds/worker/checkouts/gecko/ipc/glue/MessageChannel.cpp:1811:25
#126 0x7f3df7a5df13 in mozilla::ipc::MessageChannel::DispatchMessage(mozilla::ipc::ActorLifecycleProxy*, mozilla::UniquePtr<IPC::Message, mozilla::DefaultDelete<IPC::Message>>) /builds/worker/checkouts/gecko/ipc/glue/MessageChannel.cpp:1736:9
#127 0x7f3df7a5f02b in mozilla::ipc::MessageChannel::RunMessage(mozilla::ipc::ActorLifecycleProxy*, mozilla::ipc::MessageChannel::MessageTask&) /builds/worker/checkouts/gecko/ipc/glue/MessageChannel.cpp:1536:3
#128 0x7f3df7a60022 in mozilla::ipc::MessageChannel::MessageTask::Run() /builds/worker/checkouts/gecko/ipc/glue/MessageChannel.cpp:1634:14
#129 0x7f3df6048aff in nsThread::ProcessNextEvent(bool, bool*) /builds/worker/checkouts/gecko/xpcom/threads/nsThread.cpp:1193:16
#130 0x7f3df6056464 in NS_ProcessNextEvent(nsIThread*, bool) /builds/worker/checkouts/gecko/xpcom/threads/nsThreadUtils.cpp:480:10
#131 0x7f3df7a69f8a in mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) /builds/worker/checkouts/gecko/ipc/glue/MessagePump.cpp:330:5
#132 0x7f3df78b9a0a in RunInternal /builds/worker/checkouts/gecko/ipc/chromium/src/base/message_loop.cc:370:10
#133 0x7f3df78b9a0a in RunHandler /builds/worker/checkouts/gecko/ipc/chromium/src/base/message_loop.cc:363:3
#134 0x7f3df78b9a0a in MessageLoop::Run() /builds/worker/checkouts/gecko/ipc/chromium/src/base/message_loop.cc:345:3
#135 0x7f3df603fb2f in nsThread::ThreadFunc(void*) /builds/worker/checkouts/gecko/xpcom/threads/nsThread.cpp:391:10
#136 0x7f3e146b4b3f in _pt_root /builds/worker/checkouts/gecko/nsprpub/pr/src/pthreads/ptthread.c:201:5
#137 0x7f3e1448f189 in start_thread nptl/pthread_create.c:444:8
#138 0x7f3e1451dbcf in clone3 misc/../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
0x6310051f36c8 is located 0 bytes after 77512-byte region [0x6310051e0800,0x6310051f36c8)
allocated by thread T36 here:
#0 0x5569d5c20458 in calloc /builds/worker/fetches/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:77:3
#1 0x7f3d98469542 (/usr/lib/x86_64-linux-gnu/dri/vmwgfx_dri.so+0xa69542) (BuildId: 60cea14709f13d122c75908469400dbfeb094a60)
Thread T36 created by T0 here:
#0 0x5569d5c0849a in pthread_create /builds/worker/fetches/llvm-project/compiler-rt/lib/asan/asan_interceptors.cpp:208:3
#1 0x7f3e146a32a4 in _PR_CreateThread /builds/worker/checkouts/gecko/nsprpub/pr/src/pthreads/ptthread.c:458:14
#2 0x7f3e14690e9e in PR_CreateThread /builds/worker/checkouts/gecko/nsprpub/pr/src/pthreads/ptthread.c:533:12
#3 0x7f3df604382c in nsThread::Init(nsTSubstring<char> const&) /builds/worker/checkouts/gecko/xpcom/threads/nsThread.cpp:634:18
#4 0x7f3df6053c0e in nsThreadManager::NewNamedThread(nsTSubstring<char> const&, nsIThreadManager::ThreadCreationOptions, nsIThread**) /builds/worker/checkouts/gecko/xpcom/threads/nsThreadManager.cpp:550:12
#5 0x7f3df6061afc in NS_NewNamedThread(nsTSubstring<char> const&, nsIThread**, already_AddRefed<nsIRunnable>, nsIThreadManager::ThreadCreationOptions) /builds/worker/checkouts/gecko/xpcom/threads/nsThreadUtils.cpp:176:57
#6 0x7f3df8f5b315 in NS_NewNamedThread<15UL> /builds/worker/checkouts/gecko/xpcom/threads/nsThreadUtils.h:76:10
#7 0x7f3df8f5b315 in mozilla::gfx::CanvasRenderThread::Start() /builds/worker/checkouts/gecko/gfx/ipc/CanvasRenderThread.cpp:55:17
#8 0x7f3df8d862b0 in gfxPlatform::InitLayersIPC() /builds/worker/checkouts/gecko/gfx/thebes/gfxPlatform.cpp:1315:9
#9 0x7f3df8d7f290 in gfxPlatform::Init() /builds/worker/checkouts/gecko/gfx/thebes/gfxPlatform.cpp:974:3
#10 0x7f3df8d85ccf in GetPlatform /builds/worker/checkouts/gecko/gfx/thebes/gfxPlatform.cpp:464:5
#11 0x7f3df8d85ccf in gfxPlatform::InitializeCMS() /builds/worker/checkouts/gecko/gfx/thebes/gfxPlatform.cpp:2109:9
#12 0x7f3e0086198b in EnsureCMSInitialized /builds/worker/workspace/obj-build/dist/include/gfxPlatform.h:968:7
#13 0x7f3e0086198b in GetCMSMode /builds/worker/workspace/obj-build/dist/include/gfxPlatform.h:519:5
#14 0x7f3e0086198b in nsXPLookAndFeel::GetUncachedColor(mozilla::StyleSystemColor, mozilla::ColorScheme, mozilla::LookAndFeel::UseStandins) /builds/worker/checkouts/gecko/widget/nsXPLookAndFeel.cpp:1012:9
#15 0x7f3e00860d6f in nsXPLookAndFeel::GetColorValue(mozilla::StyleSystemColor, mozilla::ColorScheme, mozilla::LookAndFeel::UseStandins, unsigned int&) /builds/worker/checkouts/gecko/widget/nsXPLookAndFeel.cpp:992:17
#16 0x7f3e00866856 in mozilla::LookAndFeel::GetColor(mozilla::StyleSystemColor, mozilla::ColorScheme, mozilla::LookAndFeel::UseStandins) /builds/worker/checkouts/gecko/widget/nsXPLookAndFeel.cpp:1436:47
#17 0x7f3e0079836c in Color /builds/worker/workspace/obj-build/dist/include/mozilla/LookAndFeel.h:465:12
#18 0x7f3e0079836c in GetAccentColor /builds/worker/checkouts/gecko/widget/ThemeColors.cpp:91:7
#19 0x7f3e0079836c in mozilla::widget::ThemeColors::RecomputeAccentColors() /builds/worker/checkouts/gecko/widget/ThemeColors.cpp:195:20
#20 0x7f3e00797dfd in mozilla::widget::Theme::LookAndFeelChanged() /builds/worker/checkouts/gecko/widget/Theme.cpp:183:3
#21 0x7f3e0085e90f in nsXPLookAndFeel::GetInstance() /builds/worker/checkouts/gecko/widget/nsXPLookAndFeel.cpp:408:3
#22 0x7f3e00867325 in mozilla::LookAndFeel::GetThemeInfo(nsTSubstring<char>&) /builds/worker/checkouts/gecko/widget/nsXPLookAndFeel.cpp:1549:3
#23 0x7f3df5e5a7b7 in nsSystemInfo::Init() /builds/worker/checkouts/gecko/xpcom/base/nsSystemInfo.cpp:1081:5
#24 0x7f3df5fafc6f in mozilla::xpcom::CreateInstanceImpl(mozilla::xpcom::ModuleID, nsID const&, void**) /builds/worker/workspace/obj-build/xpcom/components/StaticComponents.cpp:10279:7
#25 0x7f3df5fdb212 in CreateInstance /builds/worker/checkouts/gecko/xpcom/components/nsComponentManager.cpp:184:46
#26 0x7f3df5fdb212 in nsComponentManagerImpl::GetServiceLocked(mozilla::Maybe<mozilla::detail::BaseMonitorAutoLock<mozilla::Monitor>>&, (anonymous namespace)::EntryWrapper&, nsID const&, void**) /builds/worker/checkouts/gecko/xpcom/components/nsComponentManager.cpp:971:17
#27 0x7f3df5fdc74f in nsComponentManagerImpl::GetService(mozilla::xpcom::ModuleID, nsID const&, void**) /builds/worker/checkouts/gecko/xpcom/components/nsComponentManager.cpp:1061:10
#28 0x7f3df5fc323d in mozilla::xpcom::GetServiceHelper::operator()(nsID const&, void**) const /builds/worker/workspace/obj-build/xpcom/components/StaticComponents.cpp:13058:50
#29 0x7f3df7db11ea in assign_from_helper /builds/worker/workspace/obj-build/dist/include/nsCOMPtr.h:897:7
#30 0x7f3df7db11ea in nsCOMPtr /builds/worker/workspace/obj-build/dist/include/nsCOMPtr.h:533:5
#31 0x7f3df7db11ea in GetServiceImpl /builds/worker/checkouts/gecko/js/xpconnect/src/JSServices.cpp:83:32
#32 0x7f3df7db11ea in GetService /builds/worker/checkouts/gecko/js/xpconnect/src/JSServices.cpp:130:8
#33 0x7f3df7db11ea in xpc::Services_Resolve(JSContext*, JS::Handle<JSObject*>, JS::Handle<JS::PropertyKey>, bool*) /builds/worker/checkouts/gecko/js/xpconnect/src/JSServices.cpp:153:25
#34 0x7f3e06ae326b in CallResolveOp /builds/worker/checkouts/gecko/js/src/vm/NativeObject-inl.h:683:8
#35 0x7f3e06ae326b in NativeLookupOwnPropertyInline<(js::AllowGC)1, (js::LookupResolveMode)1> /builds/worker/checkouts/gecko/js/src/vm/NativeObject-inl.h:795:14
#36 0x7f3e06ae326b in NativeGetPropertyInline<(js::AllowGC)1> /builds/worker/checkouts/gecko/js/src/vm/NativeObject.cpp:2239:10
#37 0x7f3e06ae326b in js::NativeGetProperty(JSContext*, JS::Handle<js::NativeObject*>, JS::Handle<JS::Value>, JS::Handle<JS::PropertyKey>, JS::MutableHandle<JS::Value>) /builds/worker/checkouts/gecko/js/src/vm/NativeObject.cpp:2287:10
#38 0x7f3e067703f9 in GetProperty /builds/worker/checkouts/gecko/js/src/vm/ObjectOperations-inl.h:118:10
#39 0x7f3e067703f9 in GetProperty /builds/worker/checkouts/gecko/js/src/vm/ObjectOperations-inl.h:125:10
#40 0x7f3e067703f9 in js::GetProperty(JSContext*, JS::Handle<JS::Value>, JS::Handle<js::PropertyName*>, JS::MutableHandle<JS::Value>) /builds/worker/checkouts/gecko/js/src/vm/Interpreter.cpp:4787:10
#41 0x7f3e06742b2c in GetPropertyOperation /builds/worker/checkouts/gecko/js/src/vm/Interpreter.cpp:245:10
#42 0x7f3e06742b2c in js::Interpret(JSContext*, js::RunState&) /builds/worker/checkouts/gecko/js/src/vm/Interpreter.cpp:3050:12
#43 0x7f3e0672814b in MaybeEnterInterpreterTrampoline /builds/worker/checkouts/gecko/js/src/vm/Interpreter.cpp:400:10
#44 0x7f3e0672814b in js::RunScript(JSContext*, js::RunState&) /builds/worker/checkouts/gecko/js/src/vm/Interpreter.cpp:458:13
#45 0x7f3e0672958c in js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) /builds/worker/checkouts/gecko/js/src/vm/Interpreter.cpp:612:13
#46 0x7f3e0672b506 in InternalCall /builds/worker/checkouts/gecko/js/src/vm/Interpreter.cpp:647:10
#47 0x7f3e0672b506 in js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>, js::CallReason) /builds/worker/checkouts/gecko/js/src/vm/Interpreter.cpp:679:8
#48 0x7f3e0672d356 in js::CallGetter(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, JS::MutableHandle<JS::Value>) /builds/worker/checkouts/gecko/js/src/vm/Interpreter.cpp:801:10
#49 0x7f3e06ae3bdd in CallGetter /builds/worker/checkouts/gecko/js/src/vm/NativeObject.cpp:2080:12
#50 0x7f3e06ae3bdd in GetExistingProperty<(js::AllowGC)1> /builds/worker/checkouts/gecko/js/src/vm/NativeObject.cpp:2108:12
#51 0x7f3e06ae3bdd in NativeGetPropertyInline<(js::AllowGC)1> /builds/worker/checkouts/gecko/js/src/vm/NativeObject.cpp:2256:14
#52 0x7f3e06ae3bdd in js::NativeGetProperty(JSContext*, JS::Handle<js::NativeObject*>, JS::Handle<JS::Value>, JS::Handle<JS::PropertyKey>, JS::MutableHandle<JS::Value>) /builds/worker/checkouts/gecko/js/src/vm/NativeObject.cpp:2287:10
#53 0x7f3e067703f9 in GetProperty /builds/worker/checkouts/gecko/js/src/vm/ObjectOperations-inl.h:118:10
#54 0x7f3e067703f9 in GetProperty /builds/worker/checkouts/gecko/js/src/vm/ObjectOperations-inl.h:125:10
#55 0x7f3e067703f9 in js::GetProperty(JSContext*, JS::Handle<JS::Value>, JS::Handle<js::PropertyName*>, JS::MutableHandle<JS::Value>) /builds/worker/checkouts/gecko/js/src/vm/Interpreter.cpp:4787:10
#56 0x7f3e06742b2c in GetPropertyOperation /builds/worker/checkouts/gecko/js/src/vm/Interpreter.cpp:245:10
#57 0x7f3e06742b2c in js::Interpret(JSContext*, js::RunState&) /builds/worker/checkouts/gecko/js/src/vm/Interpreter.cpp:3050:12
#58 0x7f3e0672814b in MaybeEnterInterpreterTrampoline /builds/worker/checkouts/gecko/js/src/vm/Interpreter.cpp:400:10
#59 0x7f3e0672814b in js::RunScript(JSContext*, js::RunState&) /builds/worker/checkouts/gecko/js/src/vm/Interpreter.cpp:458:13
#60 0x7f3e0672958c in js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) /builds/worker/checkouts/gecko/js/src/vm/Interpreter.cpp:612:13
#61 0x7f3e0672b506 in InternalCall /builds/worker/checkouts/gecko/js/src/vm/Interpreter.cpp:647:10
#62 0x7f3e0672b506 in js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>, js::CallReason) /builds/worker/checkouts/gecko/js/src/vm/Interpreter.cpp:679:8
#63 0x7f3e0687ddc2 in JS_CallFunctionValue(JSContext*, JS::Handle<JSObject*>, JS::Handle<JS::Value>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>) /builds/worker/checkouts/gecko/js/src/vm/CallAndConstruct.cpp:53:10
#64 0x7f3df7df415d in nsXPCWrappedJS::CallMethod(unsigned short, nsXPTMethodInfo const*, nsXPTCMiniVariant*) /builds/worker/checkouts/gecko/js/xpconnect/src/XPCWrappedJSClass.cpp:918:17
#65 0x7f3df60a1959 in PrepareAndDispatch /builds/worker/checkouts/gecko/xpcom/reflect/xptcall/md/unix/xptcstubs_x86_64_linux.cpp:115:37
#66 0x7f3df60a065a in SharedStub xptcstubs_x86_64_linux.cpp
#67 0x7f3df5fd3f30 in NS_CreateServicesFromCategory(char const*, nsISupports*, char const*, char16_t const*) /builds/worker/checkouts/gecko/xpcom/components/nsCategoryManager.cpp:682:19
#68 0x7f3e0635e5a9 in nsXREDirProvider::DoStartup() /builds/worker/checkouts/gecko/toolkit/xre/nsXREDirProvider.cpp:830:11
#69 0x7f3e0633a74e in XREMain::XRE_mainRun() /builds/worker/checkouts/gecko/toolkit/xre/nsAppRunner.cpp:5406:18
#70 0x7f3e0633d254 in XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) /builds/worker/checkouts/gecko/toolkit/xre/nsAppRunner.cpp:5862:8
#71 0x7f3e0633e451 in XRE_main(int, char**, mozilla::BootstrapConfig const&) /builds/worker/checkouts/gecko/toolkit/xre/nsAppRunner.cpp:5918:21
#72 0x5569d5c5dfb4 in do_main /builds/worker/checkouts/gecko/browser/app/nsBrowserApp.cpp:227:22
#73 0x5569d5c5dfb4 in main /builds/worker/checkouts/gecko/browser/app/nsBrowserApp.cpp:445:16
#74 0x7f3e14423a8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
SUMMARY: AddressSanitizer: heap-buffer-overflow /builds/worker/fetches/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:875:5 in memcpy
Shadow bytes around the buggy address:
0x6310051f3400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x6310051f3480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x6310051f3500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x6310051f3580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x6310051f3600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x6310051f3680: 00 00 00 00 00 00 00 00 00[fa]fa fa fa fa fa fa
0x6310051f3700: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x6310051f3780: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x6310051f3800: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x6310051f3880: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x6310051f3900: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
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
==11034==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.
Proof-of-Concept
- Please check the attached file!
- This has the same PoC as 1794292 I previously reported. This has been confirmed to work on Linux as well as macOS.
Reproduce
- open a poc.html in Firefox
- Wait a few seconds.
CREDIT Information
- Dohyun Lee (@l33d0hyun) of PK Security
|
Reporter | |
Comment 1•1 year ago
|
||
Since this also conflicts with the Linux Driver, there is a possibility of Sandbox Escape, and since the previously reported information of 1794292 (CVE-2023-29531) has been published, the possibility of ITW (in-the-wild) exists, so a quick patch is needed.
|
||
Comment 2•1 year ago
|
||
This has been confirmed to work on Linux as well as macOS.
If by "work" you mean "crash", I can't reproduce that on my Mac (on Firefox 115.0.2 which is what I assume you mean by "Firefox Stable", nor a recent Nightly build). What version of macOS?
On the Linux crash, could you open about:support and share the "Graphics" section?
|
|
Reporter | |
Comment 3•1 year ago
|
||
Test environment
Product : Firefox 117.0a1 asan build
VM : Virtualbox 7.0.8
GUEST OS : Ubuntu Desktop 23.04
Graphics
Features
Window Device Pixel Ratios 1
Compositing WebRender (Software)
Asynchronous Pan/Zoom wheel input enabled; scrollbar drag enabled; keyboard enabled; autoscroll enabled; smooth pinch-zoom enabled
WebGL 1 Driver WSI Info EGL_VENDOR: Mesa Project
EGL_VERSION: 1.4
EGL_EXTENSIONS: EGL_ANDROID_blob_cache EGL_ANDROID_native_fence_sync EGL_EXT_buffer_age EGL_EXT_image_dma_buf_import EGL_EXT_image_dma_buf_import_modifiers EGL_EXT_present_opaque EGL_EXT_swap_buffers_with_damage EGL_KHR_cl_event2 EGL_KHR_config_attribs EGL_KHR_context_flush_control EGL_KHR_create_context EGL_KHR_create_context_no_error EGL_KHR_fence_sync EGL_KHR_get_all_proc_addresses EGL_KHR_gl_colorspace EGL_KHR_gl_renderbuffer_image EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_3D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_image_base EGL_KHR_no_config_context EGL_KHR_reusable_sync EGL_KHR_surfaceless_context EGL_KHR_swap_buffers_with_damage EGL_EXT_pixel_format_float EGL_KHR_wait_sync EGL_MESA_configless_context EGL_MESA_drm_image EGL_MESA_image_dma_buf_export EGL_MESA_query_driver EGL_WL_bind_wayland_display EGL_WL_create_wayland_buffer_from_image
EGL_EXTENSIONS(nullptr): EGL_EXT_device_base EGL_EXT_device_enumeration EGL_EXT_device_query EGL_EXT_platform_base EGL_KHR_client_get_all_proc_addresses EGL_EXT_client_extensions EGL_KHR_debug EGL_EXT_platform_device EGL_EXT_platform_wayland EGL_KHR_platform_wayland EGL_EXT_platform_x11 EGL_KHR_platform_x11 EGL_EXT_platform_xcb EGL_MESA_platform_gbm EGL_KHR_platform_gbm EGL_MESA_platform_surfaceless
IsWebglOutOfProcessEnabled: 1
WebGL 1 Driver Renderer VMware, Inc. -- SVGA3D; build: RELEASE; LLVM;
WebGL 1 Driver Version 3.3 (Compatibility Profile) Mesa 23.0.2
WebGL 1 Driver Extensions GL_ARB_multisample GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_copy_texture GL_EXT_subtexture GL_EXT_texture_object GL_EXT_vertex_array GL_EXT_compiled_vertex_array GL_EXT_texture GL_EXT_texture3D GL_IBM_rasterpos_clip GL_ARB_point_parameters GL_EXT_draw_range_elements GL_EXT_packed_pixels GL_EXT_point_parameters GL_EXT_rescale_normal GL_EXT_separate_specular_color GL_EXT_texture_edge_clamp GL_SGIS_generate_mipmap GL_SGIS_texture_border_clamp GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_ARB_framebuffer_sRGB GL_ARB_multitexture GL_EXT_framebuffer_sRGB GL_IBM_multimode_draw_arrays GL_IBM_texture_mirrored_repeat GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_transpose_matrix GL_EXT_blend_func_separate GL_EXT_fog_coord GL_EXT_multi_draw_arrays GL_EXT_secondary_color GL_EXT_texture_env_add GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod_bias GL_INGR_blend_func_separate GL_NV_blend_square GL_NV_light_max_exponent GL_NV_texgen_reflection GL_NV_texture_env_combine4 GL_S3_s3tc GL_SUN_multi_draw_arrays GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_EXT_framebuffer_object GL_EXT_texture_compression_s3tc GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_MESA_window_pos GL_NV_packed_depth_stencil GL_NV_texture_rectangle GL_ARB_depth_texture GL_ARB_occlusion_query GL_ARB_shadow GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_mirrored_repeat GL_ARB_window_pos GL_ATI_fragment_shader GL_EXT_stencil_two_side GL_EXT_texture_cube_map GL_NV_depth_clamp GL_NV_fog_distance GL_NV_half_float GL_APPLE_packed_pixels GL_ARB_draw_buffers GL_ARB_fragment_program GL_ARB_fragment_shader GL_ARB_shader_objects GL_ARB_vertex_program GL_ARB_vertex_shader GL_ATI_draw_buffers GL_ATI_texture_env_combine3 GL_ATI_texture_float GL_EXT_shadow_funcs GL_EXT_stencil_wrap GL_MESA_pack_invert GL_NV_primitive_restart GL_ARB_depth_clamp GL_ARB_fragment_program_shadow GL_ARB_half_float_pixel GL_ARB_occlusion_query2 GL_ARB_point_sprite GL_ARB_shading_language_100 GL_ARB_sync GL_ARB_texture_non_power_of_two GL_ARB_vertex_buffer_object GL_ATI_blend_equation_separate GL_EXT_blend_equation_separate GL_OES_read_format GL_ARB_color_buffer_float GL_ARB_pixel_buffer_object GL_ARB_texture_compression_rgtc GL_ARB_texture_float GL_ARB_texture_rectangle GL_EXT_packed_float GL_EXT_pixel_buffer_object GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_rgtc GL_EXT_texture_rectangle GL_EXT_texture_sRGB GL_EXT_texture_shared_exponent GL_ARB_framebuffer_object GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_packed_depth_stencil GL_ARB_vertex_array_object GL_ATI_separate_stencil GL_EXT_draw_buffers2 GL_EXT_draw_instanced GL_EXT_gpu_program_parameters GL_EXT_gpu_shader4 GL_EXT_texture_array GL_EXT_texture_integer GL_EXT_texture_sRGB_decode GL_EXT_timer_query GL_OES_EGL_image GL_EXT_texture_buffer_object GL_ARB_copy_buffer GL_ARB_depth_buffer_float GL_ARB_draw_instanced GL_ARB_half_float_vertex GL_ARB_instanced_arrays GL_ARB_map_buffer_range GL_ARB_texture_buffer_object GL_ARB_texture_rg GL_ARB_texture_swizzle GL_ARB_vertex_array_bgra GL_EXT_texture_swizzle GL_EXT_vertex_array_bgra GL_NV_conditional_render GL_AMD_conservative_depth GL_ARB_ES2_compatibility GL_ARB_blend_func_extended GL_ARB_compatibility GL_ARB_debug_output GL_ARB_draw_elements_base_vertex GL_ARB_explicit_attrib_location GL_ARB_fragment_coord_conventions GL_ARB_provoking_vertex GL_ARB_sampler_objects GL_ARB_seamless_cube_map GL_ARB_shader_texture_lod GL_ARB_texture_buffer_object_rgb32 GL_ARB_texture_multisample GL_ARB_texture_rgb10_a2ui GL_ARB_uniform_buffer_object GL_ARB_vertex_type_2_10_10_10_rev GL_EXT_provoking_vertex GL_EXT_texture_snorm GL_MESA_texture_signed_rgba GL_NV_copy_image GL_ARB_get_program_binary GL_ARB_robustness GL_ARB_separate_shader_objects GL_ARB_shader_bit_encoding GL_ARB_shader_subroutine GL_ARB_timer_query GL_ARB_viewport_array GL_EXT_direct_state_access GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_compression_dxt5 GL_ARB_compressed_texture_pixel_storage GL_ARB_conservative_depth GL_ARB_internalformat_query GL_ARB_map_buffer_alignment GL_ARB_shading_language_420pack GL_ARB_shading_language_packing GL_ARB_texture_storage GL_EXT_framebuffer_multisample_blit_scaled GL_EXT_transform_feedback GL_AMD_shader_trinary_minmax GL_ARB_ES3_compatibility GL_ARB_arrays_of_arrays GL_ARB_clear_buffer_object GL_ARB_copy_image GL_ARB_explicit_uniform_location GL_ARB_fragment_layer_viewport GL_ARB_invalidate_subdata GL_ARB_program_interface_query GL_ARB_stencil_texturing GL_ARB_texture_buffer_range GL_ARB_texture_query_levels GL_ARB_texture_storage_multisample GL_ARB_vertex_attrib_binding GL_KHR_debug GL_KHR_texture_compression_astc_ldr GL_ARB_buffer_storage GL_ARB_clear_texture GL_ARB_internalformat_query2 GL_ARB_multi_bind GL_ARB_shading_language_include GL_ARB_texture_stencil8 GL_EXT_debug_label GL_EXT_shader_integer_mix GL_ARB_direct_state_access GL_ARB_get_texture_sub_image GL_KHR_context_flush_control GL_ARB_parallel_shader_compile GL_KHR_no_error GL_KHR_texture_compression_astc_sliced_3d GL_MESA_shader_integer_functions GL_ARB_texture_filter_anisotropic GL_KHR_parallel_shader_compile GL_EXT_EGL_image_storage GL_EXT_EGL_sync GL_NV_ES1_1_compatibility
WebGL 1 Extensions ANGLE_instanced_arrays EXT_blend_minmax EXT_color_buffer_half_float EXT_float_blend EXT_frag_depth EXT_shader_texture_lod EXT_sRGB EXT_texture_compression_rgtc EXT_texture_filter_anisotropic MOZ_debug OES_element_index_uint OES_fbo_render_mipmap OES_standard_derivatives OES_texture_float OES_texture_float_linear OES_texture_half_float OES_texture_half_float_linear OES_vertex_array_object WEBGL_color_buffer_float WEBGL_compressed_texture_astc WEBGL_compressed_texture_etc WEBGL_compressed_texture_s3tc WEBGL_compressed_texture_s3tc_srgb WEBGL_debug_renderer_info WEBGL_debug_shaders WEBGL_depth_texture WEBGL_draw_buffers WEBGL_lose_context
WebGL 2 Driver WSI Info -
WebGL 2 Driver Renderer WebGL creation failed:
* WebGL 2 requires support for the following features:
transform_feedback2 (FEATURE_FAILURE_WEBGL2_OCCL)
WebGL 2 Driver Version -
WebGL 2 Driver Extensions -
WebGL 2 Extensions -
Window Protocol wayland
Desktop Environment ubuntu:gnome
Target Frame Rate 60
WebGPU Default Adapter {
"navigator.gpu.requestAdapter({})": {
"isFallbackAdapter": true,
"requestAdapterInfo()": {
"architecture": "",
"description": "",
"device": "",
"vendor": "",
"wgpuBackend": "Vulkan",
"wgpuDevice": 0,
"wgpuDeviceType": "Cpu",
"wgpuDriver": "llvmpipe",
"wgpuDriverInfo": "Mesa 23.0.2 (LLVM 15.0.7)",
"wgpuName": "llvmpipe (LLVM 15.0.7, 128 bits)",
"wgpuVendor": 65541
},
"features": [
"depth-clip-control",
"depth32float-stencil8",
"indirect-first-instance",
"rg11b10ufloat-renderable",
"texture-compression-bc",
"timestamp-query"
],
"limits": {
"maxBindGroups": 8,
"maxBindGroupsPlusVertexBuffers": 24,
"maxBindingsPerBindGroup": 640,
"maxBufferSize": 2147483647,
"maxColorAttachmentBytesPerSample": 32,
"maxColorAttachments": 8,
"maxComputeInvocationsPerWorkgroup": 1024,
"maxComputeWorkgroupSizeX": 1024,
"maxComputeWorkgroupSizeY": 1024,
"maxComputeWorkgroupSizeZ": 1024,
"maxComputeWorkgroupStorageSize": 32768,
"maxComputeWorkgroupsPerDimension": 65535,
"maxDynamicStorageBuffersPerPipelineLayout": 256,
"maxDynamicUniformBuffersPerPipelineLayout": 256,
"maxInterStageShaderComponents": 128,
"maxInterStageShaderVariables": 16,
"maxSampledTexturesPerShaderStage": 128,
"maxSamplersPerShaderStage": 32,
"maxStorageBufferBindingSize": 134217728,
"maxStorageBuffersPerShaderStage": 32,
"maxStorageTexturesPerShaderStage": 64,
"maxTextureArrayLayers": 2048,
"maxTextureDimension1D": 16384,
"maxTextureDimension2D": 16384,
"maxTextureDimension3D": 4096,
"maxUniformBufferBindingSize": 65536,
"maxUniformBuffersPerShaderStage": 15,
"maxVertexAttributes": 32,
"maxVertexBufferArrayStride": 2048,
"maxVertexBuffers": 16,
"minStorageBufferOffsetAlignment": 32,
"minUniformBufferOffsetAlignment": 32
}
}
}
WebGPU Fallback Adapter {
"navigator.gpu.requestAdapter({\"forceFallbackAdapter\":true})": {
"isFallbackAdapter": true,
"requestAdapterInfo()": {
"architecture": "",
"description": "",
"device": "",
"vendor": "",
"wgpuBackend": "Vulkan",
"wgpuDevice": 0,
"wgpuDeviceType": "Cpu",
"wgpuDriver": "llvmpipe",
"wgpuDriverInfo": "Mesa 23.0.2 (LLVM 15.0.7)",
"wgpuName": "llvmpipe (LLVM 15.0.7, 128 bits)",
"wgpuVendor": 65541
},
"features": [
"depth-clip-control",
"depth32float-stencil8",
"indirect-first-instance",
"rg11b10ufloat-renderable",
"texture-compression-bc",
"timestamp-query"
],
"limits": {
"maxBindGroups": 8,
"maxBindGroupsPlusVertexBuffers": 24,
"maxBindingsPerBindGroup": 640,
"maxBufferSize": 2147483647,
"maxColorAttachmentBytesPerSample": 32,
"maxColorAttachments": 8,
"maxComputeInvocationsPerWorkgroup": 1024,
"maxComputeWorkgroupSizeX": 1024,
"maxComputeWorkgroupSizeY": 1024,
"maxComputeWorkgroupSizeZ": 1024,
"maxComputeWorkgroupStorageSize": 32768,
"maxComputeWorkgroupsPerDimension": 65535,
"maxDynamicStorageBuffersPerPipelineLayout": 256,
"maxDynamicUniformBuffersPerPipelineLayout": 256,
"maxInterStageShaderComponents": 128,
"maxInterStageShaderVariables": 16,
"maxSampledTexturesPerShaderStage": 128,
"maxSamplersPerShaderStage": 32,
"maxStorageBufferBindingSize": 134217728,
"maxStorageBuffersPerShaderStage": 32,
"maxStorageTexturesPerShaderStage": 64,
"maxTextureArrayLayers": 2048,
"maxTextureDimension1D": 16384,
"maxTextureDimension2D": 16384,
"maxTextureDimension3D": 4096,
"maxUniformBufferBindingSize": 65536,
"maxUniformBuffersPerShaderStage": 15,
"maxVertexAttributes": 32,
"maxVertexBufferArrayStride": 2048,
"maxVertexBuffers": 16,
"minStorageBufferOffsetAlignment": 32,
"minUniformBufferOffsetAlignment": 32
}
}
}
GPU #1
Active Yes
Description SVGA3D; build: RELEASE; LLVM;
Vendor ID 0x15ad
Device ID 0x0405
Driver Vendor mesa/vmwgfx
Driver Version 23.0.2.0
RAM 0
Diagnostics
AzureCanvasBackend skia
AzureContentBackend skia
AzureFallbackCanvasBackend skia
CMSOutputProfile Empty profile data
Display0 1920x970@60Hz scales:1.000000|1.000000
DisplayCount 1
Device Reset
Decision Log
HW_COMPOSITING
default available
env blocked Acceleration blocked by platform
OPENGL_COMPOSITING
default unavailable Hardware compositing is disabled Blocklisted; failure code FEATURE_FAILURE_OPENGL_NEED_HWCOMP
WEBRENDER
default available
env blocklisted Blocklisted by gfxInfo Blocklisted; failure code FEATURE_FAILURE_SOFTWARE_GL
WEBRENDER_COMPOSITOR
default disabled Disabled by default Blocklisted; failure code FEATURE_FAILURE_DISABLED
env blocklisted Blocklisted by gfxInfo Blocklisted; failure code FEATURE_FAILURE_WEBRENDER_COMPOSITOR_DISABLED
WEBRENDER_PARTIAL
default available
WEBRENDER_SHADER_CACHE
default disabled Disabled by default Blocklisted; failure code FEATURE_FAILURE_DISABLED
runtime unavailable WebRender disabled Blocklisted; failure code FEATURE_FAILURE_WR_DISABLED
WEBRENDER_OPTIMIZED_SHADERS
default available
runtime unavailable WebRender disabled Blocklisted; failure code FEATURE_FAILURE_WR_DISABLED
WEBRENDER_ANGLE
default available
env unavailable OS not supported Blocklisted; failure code FEATURE_FAILURE_OS_NOT_SUPPORTED
WEBRENDER_DCOMP_PRESENT
default available
user disabled User disabled via pref Blocklisted; failure code FEATURE_FAILURE_DCOMP_PREF_DISABLED
env unavailable Requires GPU process Blocklisted; failure code FEATURE_FAILURE_NO_GPU_PROCESS
runtime unavailable Requires ANGLE Blocklisted; failure code FEATURE_FAILURE_DCOMP_NOT_ANGLE
WEBRENDER_SCISSORED_CACHE_CLEARS
default available
WEBGPU
default available
X11_EGL
default available
DMABUF
default available
HARDWARE_VIDEO_DECODING
default available
runtime unavailable Force disabled by gfxInfo Blocklisted; failure code FEATURE_FAILURE_VIDEO_DECODING_TEST_FAILED
DMABUF_SURFACE_EXPORT
default available
BACKDROP_FILTER
default available
CANVAS_RENDERER_THREAD
default available
ACCELERATED_CANVAS2D
default available
env blocked Disabled by Software WebRender Blocklisted; failure code FEATURE_FAILURE_DISABLED_BY_SOFTWARE_WEBRENDER
|
|
||
Comment 4•1 year ago
|
||
Might be a driver bug, but calling it sec-high to start assuming it might be our problem.
|
||
Updated•1 year ago
|
|
|
Reporter | |
Comment 5•1 year ago
|
||
Any updates on this report?
|
||
Comment 6•1 year ago
|
||
The severity field is not set for this bug.
:jgilbert, could you have a look please?
For more information, please visit BugBot documentation.
|
|
Reporter | |
Comment 7•1 year ago
|
||
I will add a disclosure deadline.
This bug is subject to a 90-day disclosure deadline. If a fix for this
issue is made available to users before the end of the 90-day deadline,
this bug report will become public 30 days after the fix was made
available. Otherwise, this bug report will become public at the deadline.
The scheduled deadline is 2023-11-06.
|
|
||
Updated•1 year ago
|
|
||
Comment 8•1 year ago
|
||
I do believe this is a driver bug but it's going to take some digging into.
Maybe poor driver handling of u8 index buffers? u8 index buffers probably aren't natively supported by hardware and need to be polyfilled by driver, but that's my only lead here.
|
|
||
Updated•1 year ago
|
|
|
||
Comment 9•1 year ago
|
||
The severity field for this bug is set to S3. However, the bug is flagged with the sec-high keyword.
:jgilbert, could you consider increasing the severity of this security bug?
For more information, please visit BugBot documentation.
|
|
Reporter | |
Comment 10•1 year ago
|
||
Hi jgilbert,
Any update to this case?
| Comment hidden (duplicate) |
|
|
Reporter | |
Comment 12•1 year ago
|
||
any update?
|
|
||
Comment 13•1 year ago
|
||
No update yet.
It needs to be repro'd an dug into, but all signs point towards "bad driver" so far.
The index buffer (casted to u8) doesn't seem suspicious:
0: 167
1: 213
2: 235
3: 65
4: 35
5: 34
6: 248
7: 101
8: 67
9: 157
10: 207
11: 4
12: 20
13: 40
14: 90
15: 109
16: 135
17: 165
18: 112
19: 64
20: 61
21: 134
22: 133
23: 107
24: 196
25: 62
26: 72
27: 190
28: 114
29: 118
30: 242
31: 244
32: 190
33: 63
34: 52
35: 112
36: 232
37: 223
38: 113
39: 45
40: 21
41: 193
42: 65
43: 157
44: 10
45: 132
46: 178
47: 38
48: 4
49: 2
50: 220
51: 169
52: 248
53: 142
54: 53
55: 133
56: 89
57: 196
58: 70
59: 181
60: 142
61: 14
62: 61
63: 230
64: 195
65: 74
66: 186
67: 13
68: 252
69: 50
70: 28
71: 66
72: 223
73: 18
74: 67
75: 26
76: 153
77: 111
78: 112
79: 18
Looks like a range of [2,252].
There's no vertex attrib array set, so these should all be pulling from generic (uniform) vertex attribs.
Vertex shader has no declared inputs, but that is supposed to be fine.
|
|
||
Comment 14•1 year ago
|
||
gl1.drawElements(gl1.POINTS, 2, gl1.UNSIGNED_BYTE,0);
This should just be asking for the first two values, so vert-id list is really just [167, 213].
|
|
||
Updated•1 year ago
|
|
||
Comment 16•1 year ago
|
||
It tried this on Ubuntu 22.04 LTS using Fx118.x on NVIDIA driver v535 (2080 Ti GPU). Opening the attached poc.html resulted in a noticeable looping effect (the text in the awesome bar kept flashing), and nothing being drawn on the main screen. I let it run for several minutes, and this behavior persisted until I closed the browser.
No application crashing was evident.
|
|
Reporter | |
Comment 17•1 year ago
|
||
The trigger for this bug operates in certain environments.
Since it operates in an environment that uses mesa, we would appreciate it if you could refer to #c3.
Additionally, there is almost a month left until the deadline for this bug.
|
|
||
Comment 18•1 year ago
|
||
Crashed instantly on Ubuntu 22.04 using Mesa 23.0.4 and Fx118.0.1 in a VMware appliance with "Accelerate 3D graphics" enabled (same system mentioned above with the 2080 Ti GPU).
|
|
||
Updated•1 year ago
|
| Comment hidden (duplicate) |
|
|
||
Comment 20•1 year ago
|
||
My WebGL lead is not currently available, but I am discussing it with another team member who can pick it up after she finishes her current priority.
|
|
||
Updated•1 year ago
|
|
Assignee | |
Comment 21•11 months ago
|
||
|
|
Assignee | |
Comment 22•11 months ago
|
||
|
|
Assignee | |
Comment 23•11 months ago
|
||
In terms of protecting users from unexpected threats, I'm inclined to simply blocklist the SVGA3D driver for WebGL, since the vendor does not appear to have security-hardening in mind on either side of the VM boundary. Blocking individual exploits based on invalid OpenGL state vector validation is an option but unless there is demand for high performance WebGL in VirtualBox/VMWare it doesn't seem necessary to have the Enable 3D Acceleration feature work in Firefox in a Linux guest.
|
|
Reporter | |
Comment 24•11 months ago
|
||
Hi ahale,
There are two weeks left until the disclosure date for this vulnerability.
Is it possible to alleviate this within two weeks?
If necessary, an extension of an additional two weeks may be offered.
I think it would be a good idea to blocklist SVGA3D itself inside the VM as mentioned in the comment above.
There seems to be no reason to use the 3D Acceleration feature in Linux guests unless specifically required.
There seems to be more of a need for security threats that arise from using that feature.
In particular, I believe that the vulnerability that arises while accessing the driver can be used for Sandbox Escape as well.
|
|
Assignee | |
Comment 25•11 months ago
|
||
We actually did put a blocklist in place for WebRender on this driver in https://bugzilla.mozilla.org/show_bug.cgi?id=1815481 but it doesn't seem to affect WebGL, so I'm working to correct the blocklist behavior so it is more comprehensive for this case - WebGL should be blocked on any WebRender software compositing mode because of copy back from GPU being slow anyway.
|
|
Reporter | |
Comment 26•11 months ago
|
||
Hi ahale,
I see. Thank you for your hard work.
|
|
Assignee | |
Comment 27•11 months ago
|
||
|
|
Assignee | |
Comment 28•11 months ago
|
||
For now, let's disable WebGL on this driver, there's a more general discussion I'd like to start on whether WebGL should be blocked by blocklists affecting WebRender (because if WebRender is blocked, we're using software compositing, so hardware WebGL is of more dubious value than it would be if WebRender was not blocked), but that discussion is more on the topic of performance and robustness, not really relevant to this security bug.
The patch I attached blocks the feature correctly but seems to present obtuse error messages users (both would ideally cite FEATURE_FAILURE_MESA_VM as their reason for blocking, but instead they complain about software rendering, and lack of WebGL backends respectively).
|
|
Assignee | |
Comment 29•11 months ago
|
||
Just to surface one of my concerns as I've spent a non-trivial amount of time thinking about this, it is reasonably likely that as soon as the WebGL blocking is landed in a stable release we will get bugs filed by web developers who are testing their WebGL websites in Linux in a virtual machine and expect it to work, I'm not sure what magnitude of reports that will be however.
|
||
Updated•11 months ago
|
|
|
Assignee | |
Comment 30•11 months ago
|
||
I'm still spending a fair amount of time in gdb trying to figure out how we select an EGL device and how we could pick a software one deliberately on this configuration (alternative approaches exist, like setting the LIBGL_ALWAYS_SOFTWARE=1 environment variable when this driver is detected, but it feels like that would be hacky and possibly not thread safe). Per discussion in the team we want to keep WebGL viable by punting it to software rendering which should have a better security stance than the vmwgfx driver, but not disable it completely.
|
|
Reporter | |
Comment 31•11 months ago
|
||
Hello,
There are 7 days left until the deadline for this report. Additional extensions are possible upon request. How much more time do you need?
|
|
Assignee | |
Comment 32•11 months ago
|
||
I would like to have the two extra weeks you offered.
While I am confident I can get the code done before the original deadline, there's a chance of breakages that would cause it to bounce after landing, and we need to uplift the change to beta and then release which itself takes a little time.
In terms of release schedule the ideal scenario is that we verify this is stable in Nightly 120, then uplift to Beta 120, then regular release of stable 120 is scheduled for November 21, which fits within your offer for extended time but not in the original deadline. Uplifting to stable is of course possible before the original deadline but it has to be in nightly and beta first and that is a very tight window.
|
|
Assignee | |
Comment 33•11 months ago
|
||
Needinfo for stransky:
I'm looking at changing https://searchfox.org/mozilla-central/rev/01a0d864a9442d0fe2dbd4beee5c88b9b46e96bd/gfx/gl/GLLibraryEGL.cpp#897 to have a case for blocked GL drivers which would use our device enumeration to find a device with an empty name which I believe should get us llvmpipe or softpipe, rather than calling gdk_display_get_default().
I'm trying to figure out how we would determine if the driver is blocked at this point in initialization, ideally hooking into the regular blocklist feature failure system.
Do you know if the blocklist has been initialized by this point? And any tips on doing this would be appreciated.
I'm going to continue prototyping this change but it's nice to know if I'm on the wrong path.
|
|
Assignee | |
Comment 34•11 months ago
|
||
I think it would actually be cleaner if we enumerate devices and simply skip ones that are known to be unstable drivers, pick the one we are looking for (gfx::gfxVars::DrmRenderDevice), and if we exhaust the options pick the software one. I have been prototyping this logic as a change to GetAndInitDeviceDisplay and calling it first before falling back to gdk_display_get_default(), it would only return nullptr if the device enumeration fails, or there are no devices after filtering out unstable ones.
I'm really not sure what the implications of this will be on startup, because I'm not familiar with each of the approaches we are iterating through in the fallback order we use, but I can see there have been a few bugs that were fixed by rearranging the startup order and this would be changing it yet again.
|
|
Reporter | |
Updated•11 months ago
|
|
|
Reporter | |
Comment 35•11 months ago
|
||
Hello,
I will accept your offer. We are extending the deadline by another two weeks.
|
|
Reporter | |
Updated•11 months ago
|
|
|
||
Comment 37•11 months ago
|
||
Ashley: I'm assuming this also affects ESR-115 and we'd want an uplift. Please correct me if 115 is unaffected or if some big change between 115 and now would make the proposed fix not work on the ESR branch or be too risky for some reason. This was reported pretty close to the branching point so the chances seem good this would be easy to apply.
|
|
||
Comment 38•11 months ago
|
||
The bug is marked as tracked for firefox120 (beta) and tracked for firefox121 (nightly). However, the bug still has low severity.
:bhood, could you please increase the severity for this tracked bug? If you disagree with the tracking decision, please talk with the release managers.
For more information, please visit BugBot documentation.
|
|
||
Updated•11 months ago
|
|
|
||
Comment 39•11 months ago
|
||
Likely the same issue as bug 1773874, possible dupe, or at least leverageable.
|
|
||
Comment 40•11 months ago
|
||
Here's a nearby place where we check the blocklist: https://searchfox.org/mozilla-central/source/gfx/gl/GLLibraryEGL.cpp#359
|
|
Reporter | |
Comment 41•11 months ago
|
||
Hi,
If this case is the same as bug 1773874 according to comment 39, this may mean an incomplete patch of bug 1773874.
However, bug 1773874 was a case where stack_chk_fail occurred due to stack buffer overflow, but this case was not alleviated and heap overflow occurred in memcpy.
|
||
Comment 42•11 months ago
|
||
(In reply to Ashley Hale [:ahale] from comment #33)
Needinfo for stransky:
I'm looking at changing https://searchfox.org/mozilla-central/rev/01a0d864a9442d0fe2dbd4beee5c88b9b46e96bd/gfx/gl/GLLibraryEGL.cpp#897 to have a case for blocked GL drivers which would use our device enumeration to find a device with an empty name which I believe should get us llvmpipe or softpipe, rather than calling gdk_display_get_default().I'm trying to figure out how we would determine if the driver is blocked at this point in initialization, ideally hooking into the regular blocklist feature failure system.
AFAIK There are two possible options:
- Set LIBGL_ALWAYS_SOFTWARE=1 around eglInitialize (and remove it after it). This is a generic way and IMHO the easy one.
- Use EGL_EXT_device_enumeration/EGL_EXT_platform_device to enumerate devices and select software one. eglinfo lists all available devices and swrast is available as a second device of vmwgfx under VirtualBox. On bare metal/AMD swrast is also available for EGL_MESA_platform_gbm.
GL Mesa driver is selected from DRM node by drmGetVersion() so MESA select default driver for given fd according to actual kernel driver. So we'll get vmwgfx as it's the kernel driver used for such device, no matter if you create GL context surfaceless/based on display or directly for the file descriptor. Also we don't set gfxVars::DrmRenderDevice() if dmabuf is disabled which is wrong. Filled Bug 1862957 for it.
If we set LIBGL_ALWAYS_SOFTWARE MESA uses swrast over drm node and doesn't check an actual underlying driver.
Note that you need to explicitly check '3D acceleration' in VirtualBox to get vmwgfx, SW driver is used instead.
|
|
||
Comment 43•11 months ago
|
||
Sets LIBGL_ALWAYS_SOFTWARE for DriverVendor::MesaVM. If we go this way we may set it somewhere else to make sure it's thread safe. Os use forceSoftware implentation as base for SW device selection.
|
||
Updated•11 months ago
|
|
|
Assignee | |
Comment 44•11 months ago
|
||
Yeah thread-safety is the reason I opted to develop a patch for egl device enumeration instead, it's delicate-looking code though so I have been going over it meticulously, and per discussion with Kelsey I'm looking at checking the blocklist first and then using a device enumeration that searches for swrast based on the blocklist decision, which should be more extensible in the long run than blocking this specific driver in the EGL enumeration.
|
|
||
Comment 45•11 months ago
•
|
||
(In reply to Ashley Hale [:ahale] from comment #44)
Yeah thread-safety is the reason I opted to develop a patch for egl device enumeration instead.
I think the egl device enumeration is not very reliable. Also if we know the driver is broken we may not be concerned to set LIBGL_ALWAYS_SOFTWARE global wide as it may affects other applications. We launch glxtest utility to get GFX renderer & co here:
it may be possible to just open render node and get driver name directly from it as MESA does:
static char *loader_get_kernel_driver_name(int fd)
{
#if HAVE_LIBDRM
char *driver;
drmVersionPtr version = drmGetVersion(fd);
if (!version) {
log_(_LOADER_WARNING, "failed to get driver name for fd %d\n", fd);
return NULL;
}
driver = strndup(version->name, version->name_len);
log_(driver ? _LOADER_DEBUG : _LOADER_WARNING, "using driver %s for %d\n",
driver, fd);
drmFreeVersion(version);
return driver;
#else
return NULL;
#endif
}
while fd is for /dev/dri/renderD128 (that's first gfx card on the system which may cover VM scenario).
|
|
Assignee | |
Comment 46•11 months ago
|
||
I mean using the blocklist to decide to put WebGL in software mode, then acting on that in egl device selection to pick the first device that has no DRM render device. In my debugging this was consistent.
|
|
||
Comment 47•11 months ago
|
||
Guys, Mesa folks are interested to look at it.
Is it already reported there? (https://gitlab.freedesktop.org/mesa/mesa/-/issues). Can I report that as security issue there?
Thanks.
|
|
||
Updated•11 months ago
|
|
|
Reporter | |
Comment 48•11 months ago
|
||
Hello,
Did not report to Mesa.
We'd appreciate it if you could also report this to Mesa!
|
|
Reporter | |
Comment 49•11 months ago
|
||
Additionally, there are 14 days left until the deadline for this report.
Please commit the patch quickly.
Thanks.
|
|
||
Comment 50•11 months ago
|
||
Bug 1862957 sets drm device regardless of dmabuf state. That may help to enumerate mesa devices.
|
|
||
Comment 51•11 months ago
|
||
CC: Red Hat/Mesa folk Jose.
|
|
||
Comment 52•11 months ago
|
||
Can I report that as security issue [to Mesa folks]?
yes, please do.
|
|
Reporter | |
Comment 53•11 months ago
|
||
Confirmed patch for bug 1862957. Please mark if this bug has been fixed.
|
|
||
Comment 54•11 months ago
|
||
(In reply to DoHyun Lee [:l33d0hyun] from comment #53)
Confirmed patch for bug 1862957. Please mark if this bug has been fixed.
Bug 1862957 allows to enumerate MESA devices at GetAndInitDeviceDisplay() as we always set DRM device:
https://searchfox.org/mozilla-central/rev/01a0d864a9442d0fe2dbd4beee5c88b9b46e96bd/gfx/gl/GLLibraryEGL.cpp#175
but it doesn't fix this bug.
| Comment hidden (duplicate) |
|
||
Comment 56•11 months ago
|
||
Moving tracking to another cycle, please change/NI me if anything changes for the 120 cycle.
|
|
Reporter | |
Comment 57•11 months ago
|
||
Hello dveditz,
There are 7 days left until the disclosure deadline.
Please update quickly.
|
|
Assignee | |
Comment 58•11 months ago
•
|
||
I've tried to get egl device selection to resolve this problem (by picking a mesa software device) but I have not gotten it to work despite extensive experimentation and debugging, it always ends up failing in eglChooseConfig to find any configs and hence webgl gets disabled (which is admittedly a safe outcome but not one we want).
The other method we have within easy reach is to set the environment variable LIBGL_ALWAYS_SOFTWARE=1, but we need to set that before any threads are created (because setenv is not very thread-safe), which I am not sure is the case when we detect this hardware, detection may need to happen earlier in startup if threads are going at this point. We could just try comment #43 and hope that setenv doesn't cause a crash. XUL may have a thread-safe wrapper for setenv/getenv however and I am going to be looking for that now (I think I saw one) that I have pivoted to this approach.
I am actively working on a patch for this that I do want to land in firefox 120 (and of course esr115) before the disclosure deadline.
|
|
Assignee | |
Comment 59•11 months ago
|
||
https://searchfox.org/mozilla-central/source/mozglue/interposers/env_interposer.cpp appears to be our thread-safe wrappers, so I think I can use setenv reasonably.
|
|
||
Comment 60•11 months ago
|
||
Don't land this because it changes ANGLE without doing a cherry-pick+vendor.
Probably don't backport this because it has a low likelihood of breaking existing
content.
|
||
Updated•11 months ago
|
|
|
||
Comment 61•11 months ago
|
||
Clearing my needinfo: Ashley's comment 58 while I was on vacation seems to be the update DoHyun was asking for. Realistically we could get this fixed on Beta by the deadline, but Fx 120 may not be realistic (we already have Release Candidate builds in testing). Not sure what the point-release schedule is.
|
|
Assignee | |
Comment 62•11 months ago
|
||
Per discussion with dveditz, we want to let the software rendering blocklist ride the trains for Fx121 (December 19), it is possible we could pull it into the Fx120 dot release (December 5) after it has been live in Nightly, but it isn't really realistic to uplift this into Fx120 (November 18) and esr115 until it has been tested in Nightly for some time.
The diff at hand alters egl device selection to pick software rendering for WebGL, which doesn't really point to the mechanism you will be disclosing.
What do you think?
|
|
Reporter | |
Comment 63•11 months ago
|
||
Hello ahale,
In that case, we will extend the final disclosure deadline until December 19th.
The patch must be provided within this period.
|
|
Reporter | |
Updated•11 months ago
|
|
|
Reporter | |
Comment 64•11 months ago
|
||
This is the final extend and no further extensions are possible.
Details about this vulnerability will be disclosure on December 19th.
|
|
||
Comment 65•11 months ago
|
||
Thank you very much. :)
|
|
Assignee | |
Comment 66•11 months ago
|
||
That is very generous, thank you :)
|
|
Reporter | |
Comment 67•11 months ago
|
||
It's evident that Mozilla is meticulously addressing each issue, and developers are putting in significant effort.
Thank you to the Mozilla team for all their hard work!
|
|
Assignee | |
Comment 68•11 months ago
|
||
Comment on attachment 9360544 [details]
Bug 1843782 - WebGL software rendering when mesa/vmwgfx driver detected r?#gfx-reviewers
Security Approval Request
- How easily could an exploit be constructed based on the patch?: Not at all easily - the patch blocklists the mesa/vmwgfx driver with a comment citing instability (and we had already blocklisted this driver for WebRender, which makes that even less interesting), nothing points to a shader compiler bug. This should be able to ride the trains for Fx121.
- 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 - driver bug
- 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?: Backports should be easy, this code has not changed much in months if not years.
- How likely is this patch to cause regressions; how much testing does it need?: As far as I know we do not have automated testing for virtualbox and vmware, so this needs to be tested in Nightly. Manual testing was performed on Ubuntu 23.04 in vmware where it successfully switched WebGL to mesa/llvmpipe software rendering, some prior testing was performed in virtualbox and I can do that again if needed but it is the same driver version with the same bug, testing on a real Ubuntu 23.04 system with AMD graphics worked as normal.
- Is Android affected?: No
|
|
Assignee | |
Comment 69•11 months ago
|
||
For those interested, I've performed manual testing of my patch on:
- Windows 11 PC:
- VMWare running Ubuntu 23.04 - behaved as expected, blocklist worked and caused it to use software webgl
- VirtualBox running Ubuntu 23.04 - tested a previous version of patch, have not tested this latest implementation, however it is the same driver as in VMWare so I expect the same detection and mitigation to work as the crash is entirely in the Mesa driver with no apparent effect on the VM host.
- Linux AMD PC:
- Ubuntu 23.04 - behaved as expected, full WebGL acceleration as normal
Not tested on NVIDIA proprietary drivers, but I can if needed.
The riskiest part of this patch is the addition of a code path to use EGL_KHR_surfaceless_context + EGL_KHR_no_config_context in combination, we previously had not been using this combination of extensions but both have existed for around a decade in mesa and nvidia driver stacks, and they exactly serve our need for setting up a WebGL context, this code path is necessary to get the software device to work. If either is missing (which I can't imagine in practice) it retains the old code path. If this code path fails the outcome is WebGL being disabled, which is still a safe failure mode (but not one we want).
|
|
Assignee | |
Comment 70•11 months ago
•
|
||
On the Mesa side I think the bug is in https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/svga/svga_tgsi_vgpu10.c?id=ccb4ea5a43e89fcc93fff98c881639223f1538e5#n5130 where it isn't asserting that first+count <= VGPU10_MAX_TEMPS (which is defined as 4096 in https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/svga/include/VGPU10ShaderTokens.h?id=ccb4ea5a43e89fcc93fff98c881639223f1538e5#n43 ).
|
|
Assignee | |
Comment 71•11 months ago
|
||
Needinfo ryanvm - once we get sec approval and other reviews sorted, can we expect to get this into Fx121 to meet the disclosure deadline?
|
|
||
Comment 72•11 months ago
|
||
(In reply to Ashley Hale [:ahale] from comment #71)
Needinfo ryanvm - once we get sec approval and other reviews sorted, can we expect to get this into Fx121 to meet the disclosure deadline?
Shouldn't be an issue.
|
|
Assignee | |
Comment 73•10 months ago
|
||
I believe I've resolved all comments on the diff and reviews are green, so I'd like to get this landed in Nightly for a few days and uplift to Beta for Fx121 so it can make it to release.
|
||
Comment 74•10 months ago
|
||
Comment on attachment 9360544 [details]
Bug 1843782 - WebGL software rendering when mesa/vmwgfx driver detected r?#gfx-reviewers
Approved to land and uplift if desired
|
||
Updated•10 months ago
|
|
|
Reporter | |
Comment 75•10 months ago
|
||
Hello ahale,
When you're ready, commit this and change it to fixed status!
|
|
||
Comment 76•10 months ago
|
||
Ashley, you're free to land this after it gets security approval. I've gone ahead and done so in the interest of getting this baking on Nightly, but please don't hesitate to do so yourself next time. Go ahead and request Beta and ESR115 approval when you get a chance also.
|
|
||
Comment 77•10 months ago
|
||
Lando hit conflicts trying to push this to autoland. Please update the patch and re-queue it.
|
|
Assignee | |
Comment 78•10 months ago
|
||
Original Revision: https://phabricator.services.mozilla.com/D192039
|
|
||
Updated•10 months ago
|
|
|
Assignee | |
Comment 79•10 months ago
|
||
(In reply to Ryan VanderMeulen [:RyanVM] from comment #76)
Ashley, you're free to land this after it gets security approval. I've gone ahead and done so in the interest of getting this baking on Nightly, but please don't hesitate to do so yourself next time. Go ahead and request Beta and ESR115 approval when you get a chance also.
I actually did press the button in Lando on Nov 21 (Tuesday), and checked back on it a couple times later in the night and saw no progress, so I was not sure if lando was broken.
Trying again today after I rebased it, and will request uplift.
|
||
Comment 80•10 months ago
|
||
|
|
||
Comment 81•10 months ago
|
||
Backed out for webgl failures:
https://hg.mozilla.org/integration/autoland/rev/408199adade8e9db1d93d2b1d55f27ba4f8072f3
Push with failures
Failure log gv-junit
Failure log webgl
Failure log reftest
|
|
Reporter | |
Comment 82•10 months ago
|
||
Hello ahale,
Now that the commit is complete, please change the status to fixed.
|
|
||
Comment 83•10 months ago
|
||
Per our standard practices, the bug will be closed when the patch merges to mozilla-central. There is no need for to ask the developer to do so.
|
|
Assignee | |
Comment 84•10 months ago
•
|
||
I am not entirely sure why context creation with no surface and no config is failing on ANGLE and Android but I will change my new approach to only happen with MOZ_WIDGET_GTK and that should clear up the failures.
|
|
||
Updated•10 months ago
|
|
|
||
Comment 85•10 months ago
|
||
|
|
||
Comment 86•10 months ago
|
||
|
|
||
Comment 87•10 months ago
•
|
||
Backed out for causing backout for causing failures complaining about RemoteProcessMonitor
Backout link
|
|
Assignee | |
Comment 88•10 months ago
|
||
I've now refactored the diff heavily to minimize changes to off-target platforms, and have automatic fallbacks for the new code paths, so it should never fail now, I've kicked off a try run in https://treeherder.mozilla.org/jobs?repo=try&revision=6f0f8be0c6a0c2575d217c84ce7216bf12eb0751 to see if it is landable.
|
|
||
Comment 89•10 months ago
|
||
|
|
Assignee | |
Comment 90•10 months ago
|
||
So it has landed and not been backed out this time? :)
|
|
||
Comment 91•10 months ago
|
||
Yes, no backout. There had been issues with pulsebot posting in bugs.
|
|
||
Comment 92•10 months ago
|
||
Looks like this is ready for Beta & ESR approval requests?
|
|
||
Comment 93•10 months ago
|
||
I think we had discussed having the OP test the fix in Nightly before going there. Ashley?
|
|
Assignee | |
Comment 96•10 months ago
•
|
||
I've downloaded and tested the latest nightly in VMware (which uses this same mesa/vmwgfx driver) and it correctly reports llvmpipe, the poc does not work anymore as far as I can tell, it did work on the stable version of Firefox in the same VM.
Can you confirm this is fixed?
If so I'll proceed to requesting the Beta uplift so that it rides the trains for Firefox 121 and meets the Dec 19 target.
|
|
Reporter | |
Comment 97•10 months ago
|
||
I also confirmed that this was resolved!
|
|
Reporter | |
Comment 98•10 months ago
|
||
The poc did not work in a patched environment.
|
|
||
Comment 99•10 months ago
|
||
The patch landed in nightly and beta is affected.
:ahale, is this bug important enough to require an uplift?
- If yes, please nominate the patch for beta approval.
- If no, please set
status-firefox121towontfix.
For more information, please visit BugBot documentation.
|
|
Assignee | |
Comment 100•10 months ago
|
||
Original Revision: https://phabricator.services.mozilla.com/D192039
|
|
||
Updated•10 months ago
|
|
|
||
Comment 101•10 months ago
|
||
Uplift Approval Request
- Explanation of risk level: Relatively low because we already blocklisted hardware WebRender when using this driver, so performance is already degraded more broadly
- Steps to reproduce for manual QE testing: Run Firefox nightly in a Linux distro, verify it does not crash on startup. To repro the vulnerability open a Ubuntu running in VMware workstation (on any host OS), load the poc from the bug and if the browser crashes the bug is present, if the browser just cycles loading the tab the mitigation is effective.
- Is Android affected?: no
- Code covered by automated testing: yes
- Risk associated with taking this patch: Performance is noticeably degraded in VMware and VirtualBox guest VMs when viewing WebGL content (e.g. Google Maps)
- String changes made/needed: N/A?
- Needs manual QE test: no
- User impact if declined: Vulnerability in WebGL could be exploited, possibly leading to sandbox escape from guest vm to host machine in VMware and/or VirtualBox
- Fix verified in Nightly: yes
|
|
Assignee | |
Comment 102•10 months ago
|
||
Original Revision: https://phabricator.services.mozilla.com/D192039
|
|
||
Updated•10 months ago
|
|
|
||
Comment 103•10 months ago
|
||
Uplift Approval Request
- Risk associated with taking this patch: Performance is noticeably degraded in VMware and VirtualBox guest VMs when viewing WebGL content (e.g. Google Maps)
- Needs manual QE test: no
- String changes made/needed: N/A?
- User impact if declined: Vulnerability in WebGL could be exploited, possibly leading to sandbox escape from guest vm to host machine in VMware and/or VirtualBox
- Fix verified in Nightly: yes
- Steps to reproduce for manual QE testing: Run Firefox nightly in a Linux distro such as Ubuntu running in VMware workstation (on any host OS), load the poc from the bug and if the browser crashes the bug is present, if the browser just cycles loading the tab the mitigation is effective.
- Explanation of risk level: Relatively low because we already blocklisted hardware WebRender when using this driver, so performance is already degraded more broadly
- Is Android affected?: no
- Code covered by automated testing: yes
|
|
Reporter | |
Updated•10 months ago
|
|
|
||
Comment 104•10 months ago
|
||
Comment on attachment 9366501 [details]
Bug 1843782 - WebGL software rendering when mesa/vmwgfx driver detected r?#gfx-reviewers
Approved for 121.0b7.
|
|
||
Comment 105•10 months ago
|
||
Comment on attachment 9366633 [details]
Bug 1843782 - WebGL software rendering when mesa/vmwgfx driver detected r?#gfx-reviewers
Approved for 115.6esr.
|
||
Updated•10 months ago
|
|
|
||
Comment 106•10 months ago
|
||
| uplift | ||
|
||
Updated•10 months ago
|
|
|
||
Updated•10 months ago
|
|
||
Updated•10 months ago
|
|
|
Reporter | |
Comment 107•10 months ago
|
||
Hello dveditz,
Can I get a bounty for this report?
|
|
Assignee | |
Comment 108•10 months ago
|
||
Original Revision: https://phabricator.services.mozilla.com/D192039
|
|
||
Updated•10 months ago
|
|
|
||
Comment 109•10 months ago
|
||
Uplift Approval Request
- Code covered by automated testing: yes
- Explanation of risk level: Relatively low because we already blocklisted hardware WebRender when using this driver, so performance is already degraded more broadly
- User impact if declined: Vulnerability in WebGL could be exploited, possibly leading to sandbox escape from guest vm to host machine in VMware and/or VirtualBox
- Needs manual QE test: no
- Risk associated with taking this patch: Performance is noticeably degraded in VMware and VirtualBox guest VMs when viewing WebGL content (e.g. Google Maps)
- Steps to reproduce for manual QE testing: Run Firefox nightly in a Linux distro, verify it does not crash on startup. To repro the vulnerability open a Ubuntu running in VMware workstation (on any host OS), load the poc from the bug and if the browser crashes the bug is present, if the browser just cycles loading the tab the mitigation is effective.
- Fix verified in Nightly: yes
- String changes made/needed: N/A?
- Is Android affected?: no
|
|
||
Comment 110•10 months ago
|
||
Uplift Approval Request
- Needs manual QE test: no
- User impact if declined: Vulnerability in WebGL could be exploited, possibly leading to sandbox escape from guest vm to host machine in VMware and/or VirtualBox
- Risk associated with taking this patch: Performance is noticeably degraded in VMware and VirtualBox guest VMs when viewing WebGL content (e.g. Google Maps)
- Code covered by automated testing: yes
- Explanation of risk level: Relatively low because we already blocklisted hardware WebRender when using this driver, so performance is already degraded more broadly
- Is Android affected?: no
- String changes made/needed: N/A?
- Steps to reproduce for manual QE testing: Run Firefox nightly in a Linux distro, verify it does not crash on startup. To repro the vulnerability open a Ubuntu running in VMware workstation (on any host OS), load the poc from the bug and if the browser crashes the bug is present, if the browser just cycles loading the tab the mitigation is effective.
- Fix verified in Nightly: yes
|
|
||
Updated•10 months ago
|
|
|
||
Comment 111•10 months ago
|
||
| uplift | ||
|
|
||
Updated•10 months ago
|
|
|
||
Comment 112•10 months ago
|
||
(In reply to DoHyun Lee [:l33d0hyun] from comment #107)
Can I get a bounty for this report?
The bug is properly flagged for consideration by the bounty team, and now that it is resolved it's in the queue. I could point to the bounty decisions on bugs that look similar, but I can't answer your question as an individual before the team meets and makes that decision.
|
||
Comment 113•10 months ago
|
||
I've reproduced this "heap-buffer-overflow" crash signature on startup with Fx 119.0a1 (2023-09-19) in VirtualBox by running Ubuntu 23.04, using Mesa 23.0.4 and "Accelerate 3D graphics" enabled.
No crash on my end with Fx 122.0a1 (2023-12-07), Fx 121.0b7 and 115.6.0esr.
|
||
Updated•10 months ago
|
|
|
||
Updated•10 months ago
|
|
|
||
Comment 114•10 months ago
|
||
|
|
||
Comment 115•10 months ago
|
||
|
|
||
Comment 116•10 months ago
|
||
|
|
||
Updated•10 months ago
|
|
||
Comment 117•9 months ago
|
||
Just curious: I have found consistent STR for bug 1855686 (where the crash stack also involves DrawElementsInstanced) on my work machine running Ubuntu 22.04. These STR lead to a crash in Firefox 120.0.1, but not in Nightly. Running mozregression suggests that it is the patch from comment 89 that fixed this crash for me. However I am not running in a VM, so is it expected that this patch can affect my setup?
|
|
Reporter | |
Comment 118•9 months ago
|
||
This is very interesting. Does this vulnerability also occur on systems using the Mesa driver? This issue can occur if the Mesa driver is used on the host as well as the VM.
|
|
Reporter | |
Comment 119•9 months ago
|
||
The patch for this bug disables the Mesa Driver. This may have alleviated bugs for all similar cases involved.
|
|
||
Comment 120•9 months ago
|
||
This is my about:support in Firefox 120.0.1 on the machine where I can reproduce the crash from bug 1855686. Reproducing the crash from bug 1855686 in 120.0.1 ASAN crashes in the same way as non-ASAN (null pointer deref, same call stack). Running poc.html in 120.0.1 ASAN does not crash Firefox on this machine.
STR for reproducing the crash from bug 1855686 (Ubuntu 22.04, also crashes with up-to-date mesa custom build):
- Open skisporet.no.
- Maximize the window.
- Zoom into Sauda area little by little (one scroll event per second).
- By the time you can see multiple ski stations, you should notice weird glitches. If you wait a bit, the browser should crash.
I have also had an instance of the crash from bug 1855688 with exactly the same STR.
|
|
||
Comment 121•9 months ago
|
||
This is my about:support in 121.0rc1 which does not reproduce any crash when following the STR.
|
|
||
Comment 122•9 months ago
|
||
See bug 1855686 comment 1 for more details about that crash. I did not include the STR there for the moment in case there is a link to this sec bug.
|
||
Comment 123•9 months ago
•
|
||
It might be worth evaluating the effect that bug 1862039 had on this. I've encountered several crashes over the past few months that were caused by lack of validation on Mesa's side because we were setting GL_CONTEXT_FLAG_NO_ERROR_BIT. Most of those crashes were NULL pointer accesses because we lost a particular element when the GL context was gone, but some were definitely out-of-bounds type of accesses (such as accessing a mip-map level that had disappeared). I'll try and dig out the corresponding crashes, anyway the fix for bug 1862039 should have put an end to all of them, losing the GL shouldn't cause us to break invariants Mesa expects and it might thus be worth uplifting.
|
|
Assignee | |
Comment 124•9 months ago
|
||
I just tried with my mitigations disabled and the poc still works, so bug 1862039 did not prevent this - Mesa may not have an actual error check for number of shader temp variables, whereas Firefox does (ANGLE shader validation) but isn't set to the correct threshold to prevent this bug on this driver, and Mesa would be the better place to prevent that.
How do you think we should proceed with uplift of bug 1862039?
|
|
||
Comment 125•9 months ago
|
||
I think uplifting it doesn't hurt, we've hit issues related to it more than once and it's going to benefit users.
| Comment hidden (offtopic) |
| Comment hidden (offtopic) |
|
|
||
Updated•9 months ago
|
|
|
||
Comment 128•9 months ago
|
||
(In reply to Ashley Hale [:ahale] from comment #30)
I'm still spending a fair amount of time in gdb trying to figure out how we select an EGL device and how we could pick a software one deliberately on this configuration (alternative approaches exist, like setting the LIBGL_ALWAYS_SOFTWARE=1 environment variable when this driver is detected, but it feels like that would be hacky and possibly not thread safe).
I had missed this comment: note that since bug 1752703 landed calling setenv() (or any other environment manipulation functions) is thread-safe.
|
|
Assignee | |
Comment 129•8 months ago
|
||
(In reply to Gabriele Svelto [:gsvelto] from comment #128)
(In reply to Ashley Hale [:ahale] from comment #30)
I'm still spending a fair amount of time in gdb trying to figure out how we select an EGL device and how we could pick a software one deliberately on this configuration (alternative approaches exist, like setting the LIBGL_ALWAYS_SOFTWARE=1 environment variable when this driver is detected, but it feels like that would be hacky and possibly not thread safe).
I had missed this comment: note that since bug 1752703 landed calling
setenv()(or any other environment manipulation functions) is thread-safe.
Good to know! I saw the code for this when I was investigating the possibility of using setenv, but I wasn't sure of the dynamic library overload order and where to look at to confirm - the getenv is in Mesa, so if they don't get our threadsafe env functions then it's still not thread safe, which I didn't articulate in describing it in the comment.
|
|
||
Comment 130•8 months ago
|
||
(In reply to Ashley Hale [:ahale] from comment #129)
the getenv is in Mesa, so if they don't get our threadsafe env functions then it's still not thread safe, which I didn't articulate in describing it in the comment.
We inject the interposers before libc, so Mesa gets to use our functions instead of libc's. The motivation behind this was to fix the races between Firefox' setenv()s and Mesa's getenv()s which were causing frequent crashes.
|
|
||
Comment 131•5 months ago
|
||
Bulk-unhiding security bugs fixed in Firefox 119-121 (Fall 2023). Use "moo-doctrine-subsidy" to filter
|
||
Updated•4 months ago
|
Description
•