Currently, xorgGlxMakeCurrent() would set the context tag only for
indirect GLX contexts.
However, several other places expect to find a context for the tag or
they would raise a GLXBadContextTag error, such as WaitGL() or WaitX().
Set the context tag for direct contexts as well, to avoid raising an
error and possibly killing the client.
Thanks to Erik Kurzinger <ekurzinger@nvidia.com> for spotting the issue.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit c468d34c72)
If a GLXMakeCurrent request specifies an X window as its drawable,
__glXGetDrawable will implicitly create a GLXWindow for it. However,
the client may have already explicitly created a GLXWindow for that X
window. If that happens, two __glXDrawableRes resources will be added
to the window.
If the explicitly-created GLXWindow is later destroyed by the client,
DrawableGone will call FreeResourceByType on the X window, but this
will actually free the resource for the implicitly-created GLXWindow,
since that one would be at the head of the list.
Then if the X window is destroyed after that, the resource for the
explicitly-created GLXWindow will be freed. But that GLXWindow was
already destroyed above. This crashes the server when it tries to call
the destroyed GLXWindow's destructor. It also means the
implicitly-created GLXWindow would have been leaked since the
FreeResourceByType call mentioned above skips calling the destructor.
To fix this, if __glXGetDrawable is given an X window, it should check
if there is already a GLXWindow associated with it, and only create an
implicit one if there is not.
Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit b7a85e44da)
A lot of that code is the same as in xf86-amdgpu and xf86-nouveau drivers. By removing that functions from
ms namespace we can move that code to common implementation.
Signed-off-by: Łukasz Spintzyk <lukasz.spintzyk@synaptics.com>
(cherry picked from commit 5be3b80b8d)
Instead of getting the current msc value from the window crtc,
which not exist take the last saved msc value saved in
the window_priv struct
Signed-off-by: Łukasz Spintzyk <lukasz.spintzyk@synaptics.com>
(cherry picked from commit d2dce22b67)
This mode for displays running on evdi/udl as side effect of failed glamor_egl_init
reverse_prime_offload_mode was initialized to FALSE
After Mesa upgrade to 21.0.0 GL_RENDERER is not llvmpipe that results in successful glamor_egl_init
and reverse_prime_offload_mode enabled.
This commit is explicitly disabling reverse_prime_offload_mode for evdi and udl drivers
Signed-off-by: Łukasz Spintzyk <lukasz.spintzyk@synaptics.com>
(cherry picked from commit 7e7c147105)
Trying to change the pointer control settings on a device without
PtrFeedbackPtr would be a bug and a crash in the Xserver.
Guard against that case by returning early with a BadImplementation
error, that might kill the X11 client but the Xserver would survive.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Related: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1137
(cherry picked from commit dee2bb033e)
Trying to change the acceleration/threshold on Xwayland cannot work, and
the corresponding handler xwl_pointer_control() is a no-op.
Yet, an X11 client trying to change those on the touch device may
possibly cause a crash because the touch device in Xwayland doesn't set
that.
Initialize the touch device's PtrFeedback to make sure that just cannot
happen.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1137
(cherry picked from commit ab76272a7d)
glxProbeDriver() concatenates __DRI_DRIVER_GET_EXTENSIONS with driver name
to get symbol name for get_extension function. Unfortunately that doesn't
work for drivers that have hyphen in their name, e.g. sun4i-drm --
get_extensions() for these uses underscore instead.
As result dlsym() doesn't find get_extension() function and AIGLX
initialization fails resulting in following message in Xorg.0.log:
(EE) AIGLX error: sun4i-drm does not export required DRI extension
Replace all non-alpha-numeric characters with underscore to fix the issue.
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
(cherry picked from commit b56e501092)
CVE-2021-3472 / ZDI-CAN-1259
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Matthieu Herrb <matthieu@herrb.eu>
This check is always true on our supported systems.
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
(cherry picked from commit 5ae47a9d579e8cb0fbe938455faea53ed75d7098)
A change during the 1.20 development cycle resulted in fbconfigs being walked
and deallocated individually during __glXScreenDestroy. This change
now avoids a use-after-free caused by that change.
==50859==ERROR: AddressSanitizer: heap-use-after-free on address 0x00010d3819c8 at pc 0x0001009d4230 bp 0x00016feca7a0 sp 0x00016feca798
READ of size 8 at 0x00010d3819c8 thread T5
#0 0x1009d422c in __glXScreenDestroy glxscreens.c:448
#1 0x10091cc98 in __glXAquaScreenDestroy indirect.c:510
#2 0x1009d2734 in glxCloseScreen glxscreens.c:169
#3 0x100740a24 in dix_main main.c:325
#4 0x10023ed50 in server_thread quartzStartup.c:65
#5 0x199ae7fd0 in _pthread_start+0x13c (libsystem_pthread.dylib:arm64e+0x6fd0)
#6 0x199ae2d38 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d38)
0x00010d3819c8 is located 200 bytes inside of 12800-byte region [0x00010d381900,0x00010d384b00)
freed by thread T5 here:
#0 0x101477ba8 in wrap_free+0x98 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3fba8)
#1 0x1009d4240 in __glXScreenDestroy glxscreens.c:449
#2 0x10091cc98 in __glXAquaScreenDestroy indirect.c:510
#3 0x1009d2734 in glxCloseScreen glxscreens.c:169
#4 0x100740a24 in dix_main main.c:325
#5 0x10023ed50 in server_thread quartzStartup.c:65
#6 0x199ae7fd0 in _pthread_start+0x13c (libsystem_pthread.dylib:arm64e+0x6fd0)
#7 0x199ae2d38 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d38)
previously allocated by thread T5 here:
#0 0x101477e38 in wrap_calloc+0x9c (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3fe38)
#1 0x100925a40 in __glXAquaCreateVisualConfigs visualConfigs.c:116
#2 0x10091cb24 in __glXAquaScreenProbe+0x224 (X11.bin:arm64+0x100730b24)
#3 0x1009cd840 in xorgGlxServerInit glxext.c:528
#4 0x10074539c in _CallCallbacks dixutils.c:743
#5 0x100932a70 in CallCallbacks callback.h:83
#6 0x100932478 in GlxExtensionInit vndext.c:244
#7 0x10020a364 in InitExtensions miinitext.c:267
#8 0x10073fe7c in dix_main main.c:197
#9 0x10023ed50 in server_thread quartzStartup.c:65
#10 0x199ae7fd0 in _pthread_start+0x13c (libsystem_pthread.dylib:arm64e+0x6fd0)
#11 0x199ae2d38 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d38)
Regressed-in: 4b0a3cbab1
CC: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
(cherry picked from commit 487286d472)
Everything declared in it comes from quartz.c, so match reality.
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
(cherry picked from commit f51b97b0de)
It violates @autoreleasepool best practices, and this helps collapse quartzCocoa.m into quartz.c
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
(cherry picked from commit 94e4e17348)
There is a place where this code was called on the main thread.
We're using a rather nasty anti-pattern to just call a block inline rather
than synchonously calling it on the main thread if we're already on the main
thread. This code could use a good overhaul, but I don't have time to rip
it apart right now. This will address the immediate issue.
Fixes: https://github.com/XQuartz/XQuartz/issues/40
Fixes: https://github.com/XQuartz/XQuartz/issues/48
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
(cherry picked from commit c9a3b14c14)