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>
The OS abstraction isn't really the right place for those flags,
they are're probably better off in their corresponding extensions.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1519>
It's more robust / easier understandable programming style to use explicit
switch statements, case'ing on the constants defined in the protocol header,
instead of implicitly via a some opaque call table. It's also done this
way in the other extensions, so making the code a bit more consistent.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1591>
When using struct initializers, all fields not set explicitly are zero.
Also no need to swap fields that are known to be zero.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1591>
The `majorVersion` and `minorVersion` fields are CARD16, thus need to be swapped.
OTOH, the lengths field is zero anyways, so no need to swap it.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1591>
Right now, we're assuming that even when deep nesting involved, the proc
vector is always set to a valid function. One the one hand it requires
extra dummy procs in some cases, OTOH it's making upcoming refactoring
of the code flow unnecessarily complex.
The big plot (of subsequent commits) is splitting out the extension's
(and possibly subsystem's) special logic out of the wrapping chain and
let them be executed independently from the DDX/drivers - when applicable
even only when the pixmap is really destroyed (not just unref'ed).
(At some later point, it might even become be actually a valid situation
that DestroyPixmap vector really being NULL.)
See: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1754
See: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1755
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1709>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1639>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1639>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1639>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1639>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1639>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1639>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1639>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1639>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1639>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1639>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1639>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1639>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1639>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1639>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1639>
The authorative source of the request frame size is client->req_len,
especially with big requests larger than 2^18 bytes.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1639>
The authorative source of the request frame size is client->req_len,
especially with big requests larger than 2^18 bytes.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1639>
The authorative source of the request frame size is client->req_len,
especially with big requests larger than 2^18 bytes.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1639>
The authorative source of the request frame size is client->req_len,
especially with big requests larger than 2^18 bytes.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1639>
The authorative source of the request frame size is client->req_len,
especially with big requests larger than 2^18 bytes.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1639>
Most of the complexity here isn't needed at all. It can be really trivial,
since we just have one operation anyways.
It's also much cleaner to use the defines from proto headers instead of
raw numbers.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1596>
PANORAMIX was the original working title of the extension, before it became
official standard. Just nobody cared about fixing the symbols to the official
naming.
For backwards compatibility with drivers, the old PANORAMIX symbol will
still be set.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1258>
The client.h file is part of the public module API, but it also contains
definitions that aren't useful for being used in modules. Splitting them
out into their own client_priv.h file, which isn't part of the API.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The symbol controls whether to include dix-config.h, and it's always set,
thus we don't need it (and dozens of ifdef's) anymore.
This commit only removes them from our own source files, where we can
guarantee that dix-config.h is present - leaving the (potentially exported)
headers untouched.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Split reply header and payload buffers. Making it more coherent with all the
other request handlers, and allows a lot of further simplification by using
generic macros (coming in subsequent commits).
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1600>
There's some piece ifdef'ed code that doesn't serve any practical purpose.
Instead add a little comment telling why that funny way of dispatching
(based on request size) is necessary.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1600>
We alread have several of these calls, that aren't interested in result value,
explicitly casting to void. Fixing this up for the remaining ones.
This is helpful for the human reader as well as quality analysis tools.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1648>
Couldn't find a trace where it actually had been used, so there doesn't
seem to be any reason while still keeping it around.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1512>
Several places using _X_ATTRIBUTE_PRINTF macro from X11/Xfuncproto.h
but missing to include it, so it depends on other headers whether it's
included by mere accident, which quickly causes trouble if include order
changes. Cleaning that up by adding explicit include statements.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1580>
We can directly use calloc() as all other places do.
If we wanna have an convenient macro for struct allocation, that would be the
job of a separate patch queue and should be done consequently, treewide.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1586>
he generic XaceHook() call isn't typesafe (und unnecessarily slow).
Better add an explicit function, just like we already have for others.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1556>
he generic XaceHook() call isn't typesafe (und unnecessarily slow).
Better add an explicit function, just like we already have for others.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1556>
he generic XaceHook() call isn't typesafe (und unnecessarily slow).
Better add an explicit function, just like we already have for others.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1556>
he generic XaceHook() call isn't typesafe (und unnecessarily slow).
Better add an explicit function, just like we already have for others.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1556>
he generic XaceHook() call isn't typesafe (und unnecessarily slow).
Better add an explicit function, just like we already have for others.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1556>
he generic XaceHook() call isn't typesafe (und unnecessarily slow).
Better add an explicit function, just like we already have for others.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1556>
The generic XaceHook() call isn't typesafe (und unnecessarily slow).
Better add an explicit function, just like we already have for others.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1556>
The generic XaceHook() call isn't typesafe (und unnecessarily slow).
Better add an explicit function, just like we already have for others.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1556>
The generic XaceHook() call isn't typesafe (und unnecessarily slow).
Better add an explicit function, just like we already have for others.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1556>
The generic XaceHook() call isn't typesafe (und unnecessarily slow).
Better add an explicit function, just like we already have for others.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1556>
The generic XaceHook() call isn't typesafe (und unnecessarily slow).
Better add an explicit function, just like we already have for others.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1556>
The secur.h doesn't need the symbols defined here (eg. Status or Display)
anymore, so no need to keep it around anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1550>
Make sure everybody who needs stuff from <sys/mman.h> actually includes it,
and dropped the include from xf86_OSlib.h.
Check for all symbols defined by Open Group spec.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1412>
Since we already had to rename some of them, in order to fix name clashes
on win32, it's now time to rename all the remaining ones.
The old ones are still present as define's to the new ones, just for
backwards compatibility.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1355>
Windows' native headers using some our RT_* define's names for other things.
Since the naming isn't very nice anyways, introducing some new ones
(X11_RESTYPE_NONE, X11_RESTYPE_FONT, X11_RESTYPE_CURSOR) and define the old
ones as an alias to them, in case some out-of-tree code still uses them.
With thins change, we don't need to be so extremely careful about include
ordering and have explicit #undef's in order to prevent name clashes on
Win32 targets.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1355>
public server module API headers shouldn't be clobbered with non-exported
definitions, so move them out to private header file.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1293>
Public module API headers don't need / shouldn't to contain anything that
isn't part of the API (non-exported functions, etc).
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1287>
* this symbol is a server configuration flag (can be passed via cmdline)
for limiting the max size of big-requests. there shouldn't be any need
to use it outside the core X server (in server modules like drivers
or external extension) - therefore unexport it
* in order to reduce namespace pollution of public (server module API)
headers, create a new internal header for those tings (more to come)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1275>
This breaks the xf86-input-synaptics driver:
synaptics.c: In function 'clickpad_guess_clickfingers':
synaptics.c:2638:5: error: implicit declaration of function 'BUG_RETURN_VAL' [-Werror=implicit-function-declaration]
2638 | BUG_RETURN_VAL(hw->num_mt_mask > sizeof(close_point) * 8, 0);
This reverts commit 442aec2219.
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1316>
Yet another step of uncluttering includes: move out the BUG_* macros
into a separate header, which then is included as-needed.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
XTest requests lets the client specify a device ID, only if none
is specified do we fall back to the XTEST special device.
As of commit
aa4074251 input: Add new hook DeviceSendEventsProc for XTEST
regular devices are no longer able to send XTest events because they
have no sendEventsProc set.
This caused issue #1574 and the crash was fixed with commit
e820030de xtest: Check whether there is a sendEventsProc to call
but we still cannot send XTest events through a specific device.
Fix this by defaulting every device to the XTest send function and
punting it to the DDX (i.e. Xwayland) to override the devices as
necessary.
Fixes e820030de2
Fixes aa4074251f
This allows applications to respond to changes of power level
of a monitor, e.g. an application may stop rendering and related
calculations when the monitor is off.
Related bug: https://bugs.freedesktop.org/57120
Signed-off-by: Alexander Volkov <avolkov@astralinux.ru>
If a client tries to send XTEST events while there is no sendEventsProc
defined for the given device, Xwayland would call into 0x0 and crash.
Make sure the handler is defined before trying to use it, to avoid the
crash.
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/1574
For Xwayland, we need to be able to send the events that would normally
be processed by the normal Xserver event processing to be forwarded to
the Wayland compositor (somehow).
Add a new hook “DeviceSendEventsProc” attached to the device so that
Xwayland can implement its own routine instead of the “normal” XTEST
implementation which generates and processes X input events.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
In commit b320ca0 the mask was inadvertently changed from octal 0177 to
hexadecimal 0x177.
Fixes commit b320ca0ffe
Xtest: disallow GenericEvents in XTestSwapFakeInput
Found by Stuart Cassoff
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This fixes a use-after-free bug:
When a client first calls ScreenSaverSetAttributes(), a struct
ScreenSaverAttrRec is allocated and added to the client's
resources.
When the same client calls ScreenSaverSetAttributes() again, a new
struct ScreenSaverAttrRec is allocated, replacing the old struct. The
old struct was freed but not removed from the clients resources.
Later, when the client is destroyed the resource system invokes
ScreenSaverFreeAttr and attempts to clean up the already freed struct.
Fix this by letting the resource system free the old attrs instead.
CVE-2022-46343, ZDI-CAN 19404
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
This fixes a use-after-free bug:
When a client first calls XvdiSelectVideoNotify() on a drawable with a
TRUE onoff argument, a struct XvVideoNotifyRec is allocated. This struct
is added twice to the resources:
- as the drawable's XvRTVideoNotifyList. This happens only once per
drawable, subsequent calls append to this list.
- as the client's XvRTVideoNotify. This happens for every client.
The struct keeps the ClientPtr around once it has been added for a
client. The idea, presumably, is that if the client disconnects we can remove
all structs from the drawable's list that match the client (by resetting
the ClientPtr to NULL), but if the drawable is destroyed we can remove
and free the whole list.
However, if the same client then calls XvdiSelectVideoNotify() on the
same drawable with a FALSE onoff argument, only the ClientPtr on the
existing struct was set to NULL. The struct itself remained in the
client's resources.
If the drawable is now destroyed, the resource system invokes
XvdiDestroyVideoNotifyList which frees the whole list for this drawable
- including our struct. This function however does not free the resource
for the client since our ClientPtr is NULL.
Later, when the client is destroyed and the resource system invokes
XvdiDestroyVideoNotify, we unconditionally set the ClientPtr to NULL. On
a struct that has been freed previously. This is generally frowned upon.
Fix this by calling FreeResource() on the second call instead of merely
setting the ClientPtr to NULL. This removes the struct from the client
resources (but not from the list), ensuring that it won't be accessed
again when the client quits.
Note that the assignment tpn->client = NULL; is superfluous since the
XvdiDestroyVideoNotify function will do this anyway. But it's left for
clarity and to match a similar invocation in XvdiSelectPortNotify.
CVE-2022-46342, ZDI-CAN 19400
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
XTestSwapFakeInput assumes all events in this request are
sizeof(xEvent) and iterates through these in 32-byte increments.
However, a GenericEvent may be of arbitrary length longer than 32 bytes,
so any GenericEvent in this list would result in subsequent events to be
misparsed.
Additional, the swapped event is written into a stack-allocated struct
xEvent (size 32 bytes). For any GenericEvent longer than 32 bytes,
swapping the event may thus smash the stack like an avocado on toast.
Catch this case early and return BadValue for any GenericEvent.
Which is what would happen in unswapped setups anyway since XTest
doesn't support GenericEvent.
CVE-2022-46340, ZDI-CAN 19265
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Correctness is ensured be checking md5sum result before and after the
commit (it's the same).
Fixes LGTM warning: "Comparison is always true because firstValuator <= 1."
Signed-off-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
ZDI-CAN-14951, CVE-2021-4010
This vulnerability was discovered and the fix was suggested by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
All of these uses were attempting to set FD_CLOEXEC, which happens to be
(1<<0). Since flags is going to be aligned in memory, its address is
never going to have the low bit set, so we were never actually setting
what we meant to.
Fixes: xorg/xserver#1114
With autoconf, hashtable support is built along with Xres support.
Yet, glvnd also use it, so when disabling Xres from configure, the
build will fail at link time because hashtable functions are not
available.
Untie the build of hashtable from Xres support, just like meson build
does.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1091
Most (but not all) of these were found by using
codespell --builtin clear,rare,usage,informal,code,names
but not everything reported by that was fixed.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
If a client is in the process of being closed down, then its client->osPrivate
pointer will be set to NULL by CloseDownConnection. This can cause a crash if
freeing the client's resources results in a call to AttendClient. For example,
if the client has a pending sync fence:
Thread 1 "X" received signal SIGSEGV, Segmentation fault.
AttendClient (client=0x5571c4aed9a0) at ../os/connection.c:942
(gdb) bt
#0 AttendClient (client=0x5571c4aed9a0) at ../os/connection.c:942
#1 0x00005571c3dbb865 in SyncAwaitTriggerFired (pTrigger=<optimized out>) at ../Xext/sync.c:694
#2 0x00005571c3dd5749 in miSyncDestroyFence (pFence=0x5571c5063980) at ../miext/sync/misync.c:120
#3 0x00005571c3dbbc69 in FreeFence (obj=<optimized out>, id=<optimized out>) at ../Xext/sync.c:1909
#4 0x00005571c3d7a01d in doFreeResource (res=0x5571c506e3d0, skip=skip@entry=0) at ../dix/resource.c:880
#5 0x00005571c3d7b1dc in FreeClientResources (client=0x5571c4aed9a0) at ../dix/resource.c:1146
#6 FreeClientResources (client=0x5571c4aed9a0) at ../dix/resource.c:1109
#7 0x00005571c3d5525f in CloseDownClient (client=0x5571c4aed9a0) at ../dix/dispatch.c:3473
#8 0x00005571c3d55eeb in Dispatch () at ../dix/dispatch.c:492
#9 0x00005571c3d59e96 in dix_main (argc=3, argv=0x7ffe7854bc28, envp=<optimized out>) at ../dix/main.c:276
#10 0x00007fea4837cb6b in __libc_start_main (main=0x5571c3d1d060 <main>, argc=3, argv=0x7ffe7854bc28, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffe7854bc18) at ../csu/libc-start.c:308
#11 0x00005571c3d1d09a in _start () at ../Xext/sync.c:2378
(gdb) print client->osPrivate
$1 = (void *) 0x0
Since the client is about to be freed, its ignore count doesn't matter and
AttendClient can simply be a no-op. Check for client->clientGone in AttendClient
and remove similar checks from two callers that had them.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
This ensures that any prep work for the drawable we're about to read
from is already done before we call down to GetImage. This should be no
functional change as most of the callers with a non-trivial
SourceValidate are already wrapping GetImage and doing the equivalent
thing, but we'll be simplifying that shortly.
More importantly this ensures that if any of that prep work would
generate events - like automatic compositing flushing rendering to a
parent pixmap which then triggers damage - then it happens entirely
before we start writing the GetImage reply header.
Note that we do not do the same for GetSpans, but that's okay. The only
way to get to GetSpans is through miCopyArea or miCopyPlane - where the
callers must already call SourceValidate - or miGetImage - which this
commit now protects with SourceValidate.
Fixes: xorg/xserver#902
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
As shown by DRI3 adding the SyncCreateFenceFromFD() function, extensions may
want to create a fence, then initialize it in their own way. This currently
can't be done without adding a function directly to Xext/sync.c due to the fact
that the RTFence resource type is private and there is no external interface to
add to it.
To facilitate other X extensions creating fences and initializing them, this
change exports SyncCreate() and adds the resource directly within it. Callers no
longer need to call AddResource() after SyncCreate(), they only need to
initialize the SyncObject.
To prevent FreeFence() and FreeCounter() from segfaulting if the call to
AddResource() fails before the sync object is initialized, this adds a new
'initialized' parameter to SyncObject that, when FALSE, causes FreeFence() and
FreeCounter() to skip de-initialization and simply free the object.
Initialization after adding the resource shouldn't otherwise be a problem due to
the single-threaded nature of X.
Signed-off-by: Alex Goins <agoins@nvidia.com>
Reviewed-by: James Jones <jajones@nvidia.com>
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
It doesn't require shared memory dir and thus allows
to avoid cases when this dir is detected incorrectly,
as in https://bugreports.qt.io/browse/QTBUG-71440
Signed-off-by: Alexander Volkov <a.volkov@rusbitech.ru>
Prodding the builder's filesystem for tmp dirs doesn't necessarily
tell you anything about what the actual host's filesystem is going to
look like, so we should just try the dirs at runtime.
Signed-off-by: Eric Anholt <eric@anholt.net>
Otherwise if the VERIFY_SHMSIZE macro fails we leak the drawables
we allocated earlier.
Noticed by coverity scan.
Signed-off-by: Dave Airlie <airlied@redhat.com>
../Xext/xselinux_ext.c: In function ‘SELinuxExtensionInit’:
../Xext/xselinux_ext.c:692:21: warning: variable ‘extEntry’ set but not used [-Wunused-but-set-variable]
Signed-off-by: Adam Jackson <ajax@redhat.com>
Control flow is:
PanoramiXMaybeAddDepth() allocates an array size 240 (pDepth->numVisuals)
PanoramiXMaybeAddVisual() finds up to 270 matches (pScreen->numVisuals)
and writes those into the previously allocated array.
This caused invalid reads/writes followed by eventually a double-free abort.
Reproduced with xorg-integration-tests server test
XineramaTest.ScreenCrossing/* (and a bunch of others).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Any DPMS timeout values set in ServerFlags section of the xorg.conf
are being overwritten by DPMS extension initialization. Therefore
change the DPMS initialization of timeout values to be conditional on
not set from config.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106963
Signed-off-by: John Lumby <johnlumby@hotmail.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Avoid access to System V shared memory segment on the X server side
for clients forwarded via SSH. Also prevent them from hanging while
waiting for the reply from the ShmCreateSegment request.
v2: Allow ShmQueryVersion request even for remote clients
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=11080
Signed-off-by: Alexander Volkov <a.volkov@rusbitech.ru>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Seems that while glxvnd relies on some of the hashtable functions in
Xext, we only build hashtable support for Xext if we're also building
the res extension. This leads to some errors if you try to build glx
without res enabled:
glx/liblibglxvnd.a(vndcmds.c.o): In function `LookupVendorPrivDispatch':
/home/lyudess/Projects/xserver/glx/vndcmds.c:65: undefined reference to `ht_find'
/home/lyudess/Projects/xserver/glx/vndcmds.c:67: undefined reference to `ht_add'
glx/liblibglxvnd.a(vndcmds.c.o): In function `GlxDispatchInit':
/home/lyudess/Projects/xserver/glx/vndcmds.c:405: undefined reference to `ht_generic_compare'
/home/lyudess/Projects/xserver/glx/vndcmds.c:405: undefined reference to `ht_generic_hash'
/home/lyudess/Projects/xserver/glx/vndcmds.c:405: undefined reference to `ht_create'
glx/liblibglxvnd.a(vndcmds.c.o): In function `GlxDispatchReset':
/home/lyudess/Projects/xserver/glx/vndcmds.c:468: undefined reference to `ht_destroy'
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
So, make sure that hashtable.c gets both for both glx and res
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Install missing headers to the SDK directory to allow external modules
to properly build against the SDK. After this commit, the list of files
installed in the SDK include directory is the same as the list of files
installed by the autotools-based build.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
This field was defined as a Bool in the protocol headers and BOOL in
xcb. Bool is not a valid type for protocol fields. It is defined as
'int' by Xdefs.h, which we expect to be 32-bits on all machines.
The protocol headers and xcb have patches posted to switch to CARD32,
which is at least well defined.
This change adds the necessary byte swapping to handle other-endian
clients with this 32-bit field, and then changes the request
processing to compare all 32-bits against zero so that it works with
both new and old clients.
On MSB machines, Xlib will continue to work properly, but old XCB will
not interoperate with the X server (either before or after this patch).
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Mihai Moldovan <ionic@ionic.de>
Reviewed-by: Adam Jackson <ajax@redhat.com>
xsync: Fix diffgreater comparison
While transitioning from CARD64 to int64,
the GreaterThan call was mistakenly transformed into ">=".
Part of this was fixed already in
commit 8060196a3e
This patch fixes the remaining issue.
Signed-off-by: David Weinehall <david.weinehall@linux.intel.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Olivier Fourdan
Enrico Weigelt, metux IT consult
Alan Coopersmith
Peter Hutterer
Alexander Volkov
Konstantin Kharlamov
Povilas Kanapickas
Adam Jackson
Demi Marie Obenour
Jan Beich
Aaron Plattner
Alex Goins
Alexander Volkov
Eric Anholt
Dave Airlie
John Lumby
Lyude Paul
Michal Srb
Thierry Reding
Keith Packard
David Weinehall