This header has now become obsolete. There're also no external consumers
(drivers, etc) left, so it now finally can be dropped entirely.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used by any external module (eg drivers), so no need to keep it
exported. Also documenting it.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The pointer to the window properties is currently inside the WindowOptional
structure, which may or may not exist at any given time. Thus, before accessing
those fields, at least need to check whether it exists, potentially need to
create it first.
Since a pointer is small (in relation to WindowRec) and windows having properties
is a pretty common, we can make our life much simpler here by moving the pointer
directly into WindowRec, so we don't need extra WindowOptionalRec allocation.
This also fixes an analyzer warning on potential NULL dereference issue:
| ../dix/property.c: In function ‘dixChangeWindowProperty’:
|../dix/property.c:343:37: warning: dereference of NULL ‘*pWin.optional’ [CWE-476] [-Wanalyzer-null-dereference]
| 343 | pProp->next = pWin->optional->userProps;
| | ~~~~~~~~~~~~~~^~~~~~~~~~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Even though risk of being actually hit is minimal, better having some extra
safety checks instead of segfaulting, just in case.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
| ../Xext/panoramiXprocs.c: In function ‘PanoramiXCopyArea’:
| ../Xext/panoramiXprocs.c:1152:13: warning: use of uninitialized value ‘pGC’ [CWE-457] [-Wanalyzer-use-of-uninitialized-value]
| 1152 | if (pGC && pGC->graphicsExposures) {
| | ^~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Even though these probably never happen, it's still better having some
(really cheap) extra checks, just in case.
| ../Xext/xtest.c: In function ‘ProcXTestFakeInput’:
| ../Xext/xtest.c:385:17: warning: dereference of NULL ‘dev’ [CWE-476] [-Wanalyzer-null-dereference]
| 385 | if (!dev->key)
| | ~~~^~~~~
| ../Xext/xtest.c:442:12: warning: dereference of NULL ‘dev’ [CWE-476] [-Wanalyzer-null-dereference]
| 442 | if (dev->sendEventsProc)
| | ~~~^~~~~~~~~~~~~~~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Try not to rely on deep black magic of calloc(), instead skip the whole
part of nrects is zero.
| ../Xext/shape.c: In function ‘ProcShapeGetRectangles’:
| ../Xext/shape.c:995:24: warning: dereference of possibly-NULL ‘rects’ [CWE-690] [-Wanalyzer-possible-null-dereference]
| 995 | rects[i].x = box->x1;
| | ~~~~~~~~~~~^~~~~~~~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
> ../Xext/xres.c: In function ‘DestroyFragments’:
> ../Xext/xres.c:124:9: warning: ‘free’ of ‘it’ which points to memory on the stack [CWE-590] [-Wanalyzer-free-of-non-heap]
> 124 | free(it);
> | ^~~~~~~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
FOR_NSCREENS() is just alias for FOR_NSCREENS_BACKWARD(). In many cases
it really matters that we're going backwards and the last iteration visited
the screen #0, and that one is panoramix-wrapped.
Thus directly calling FOR_NSCREENS_BACKWARD() here and dropping the alias.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The include has become empty now. Not used by any external drivers,
so it can be dropped now.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
* not used by any external drivers, so no need to keep it exported
* choose better fitting name: InputDevGetSpriteCursor()
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
There's really no practical use for disabling GEEext, would just
cause the Xserver misbehaviour (eg. missing byte swapping)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1812>
SyncChangeAlarmAttributes() would apply the various changes while
checking for errors.
If one of the changes triggers an error, the changes for the trigger,
counter or delta value would remain, possibly leading to inconsistent
changes.
Postpone the actual changes until we're sure nothing else can go wrong.
Related to CVE-2025-26601, ZDI-CAN-25870
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1828>
We do not want to return a failure at the very last step in
SyncInitTrigger() after having all changes applied.
SyncAddTriggerToSyncObject() must not fail on memory allocation, if the
allocation of the SyncTriggerList fails, trigger a FatalError() instead.
Related to CVE-2025-26601, ZDI-CAN-25870
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1828>
In SyncInitTrigger(), we would set the CheckTrigger function before
validating the counter value.
As a result, if the counter value overflowed, we would leave the
function SyncInitTrigger() with the CheckTrigger applied but without
updating the trigger object.
To avoid that issue, move the portion of code checking for the trigger
check value before updating the CheckTrigger function.
Related to CVE-2025-26601, ZDI-CAN-25870
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1828>
When changing an alarm, the change mask values are evaluated one after
the other, changing the trigger values as requested and eventually,
SyncInitTrigger() is called.
SyncInitTrigger() will evaluate the XSyncCACounter first and may free
the existing sync object.
Other changes are then evaluated and may trigger an error and an early
return, not adding the new sync object.
This can be used to cause a use after free when the alarm eventually
triggers.
To avoid the issue, delete the existing sync object as late as possible
only once we are sure that no further error will cause an early exit.
CVE-2025-26601, ZDI-CAN-25870
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1828>
Commit 36dd28129b had an ugly typo
(probably broke on rebase - shame on myself) causing SProcGEQueryVersion()
calling itself recursively. Obviously, ProcGEQueryVersion() needs
to be called instead.
Fixes: 36dd28129b
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1817>
Not used by any external modules, so no need to keep it in public API.
Since it's used by DRI, still needs the _X_EXPORT flag, as long as DRI
is a dynamically loaded module.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1790>
Make the code a bit easier to read by using initialization of the reply
structs, at the point of declaration. Most of them aren't written to later,
just passed into WriteReplyToClient(). Also dropping some useless zero
assignments (struct initializers automatically zero-out unmentioned fields).
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1795>
Enrico Weigelt, metux IT consult
Olivier Fourdan