Previously we leaked stack when invalid enum parameters were
specified and caused __glGet*_size functions to return a 0 size.
Further, we read out-of-bounds (and leaked) when the input data was less
than 8 bytes (__glXDispSwap_GetFramebufferAttachmentParameteriv and
__glXDisp_GetRenderbufferParameteriv).
Now we only write a single element in the reply padding, and only when there
is a single element. This is what the Mesa client-side libGL expects, and
restores original GLX server behaviour, matching both pre-public (1996) SGI GLX
and XFree86 4.
The main risk of this change is if we have any error in element count or size;
previously it may not have mattered but now it does.
There are no piglit result changes from this modification using either mesa
libGLX or NVIDIA libGLX.
For performance considerations, an extra conditional and variable-length
memcpy has no meaningful impact on the indirect rendering pipeline cost.
There is still the possiblity to leak if our size checks allow an enum that
the GL implemention does not. Guarding against that requires zero-initializing
all temp storage, which wants re-evaluation of the blind 200-byte buffers
used for many calls and thus is a much bigger change.
Signed-off-by: Nathan Kidd <nkidd@rocketsoftware.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1647>
The callers of these functions were casting -1 to unsigned and then
using 4GB indexes. By returning 0 we match all the other size functions.
GLX size functions return -1 to indicate error, but GL size functions return 0.
Signed-off-by: Nathan Kidd <nkidd@rocketsoftware.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1647>
The EXT_blend_func_extended extension on ESSL always requires explicit
request to allow two FS out variables because of limitations of the ESSL
language, which is mentioned as the No.6 issue of the extension's
specification.
Fix this by adding the extension request.
The original behavior on GLES3 is slightly against the specification of
GL_EXT_blend_func_extended extension, however Mesa and older version of
PowerVR closed drivers will just ignore this issue. Newest PowerVR
closed driver will bail out on this problem, so it deems a fix now.
Fixes: ee107cd491 ("glamor: support GLES3 shaders")
Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1750>
Xwayland dispatches tablet tool tip events immediately when they arrive.
With compositors such as mutter and sway, it is not an issue because
their libinput backends synthetize axis events before tip events. In
other words, axis data and the tip status belong to different frames.
On the other hand, kwin sends axis and tip events in a single frame
(its libinput backend generates a single tip event with axis data
attached to it). Since the tip events are dispatched immediately,
they can have wrong information associated with them, for example tool
position or pressure. It results in undesired "streaks" when the user
presses the tablet tool against the tablet.
See also https://bugs.kde.org/show_bug.cgi?id=479856.
Signed-off-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2032>
The NVIDIA driver still supports GLX across physical screens in Xinerama
configurations, and uses the definitions in these headers to do that.
This reverts commit 3f469acb96.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
libwfb.so has a reference to this function:
$ nm -D ./build.debug/hw/xfree86/dixmods/libwfb.so | grep AllocColor
U AllocColor
This reverts commit b48e4a9cb7.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
libwfb.so has a reference to this function:
$ nm -D ./build.debug/hw/xfree86/dixmods/libwfb.so | grep miWindowExposures
U miWindowExposures
This reverts commit e424f49cdb.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
libwfb.so has a reference to this function:
$ nm -D ./build.debug/hw/xfree86/dixmods/libwfb.so | grep miExpandDirectColors
U miExpandDirectColors
This reverts commit c3c538784a.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
libwfb.so has a reference to this function:
$ nm -D build.debug/hw/xfree86/dixmods/libwfb.so | grep miCreateScreenResources
U miCreateScreenResources
This reverts commit d14ae53e1f.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
When changing the RandR provider property, if the property does not
already exists, it is created.
In case of error, however, it doesn't get freed, leading to a leak of
the allocated property.
Make sure to free the RandR property in case of error if was to be
added.
Found by OpenScanHub.
Fixes: 3c3a4b767 - randr: Check for overflow in RRChangeProviderProperty()
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2035>
Check for another possible integer overflow once we get a complete xReq
with BigRequest.
Related to CVE-2025-49176
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Suggested-by: Peter Harris <pharris2@rocketsoftware.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2028>
