SProcVidModeSwitchToMode() only byte-swapped the screen field (CARD32)
from the 52-byte xXF86VidModeSwitchToModeReq struct. All other fields
were passed to ProcVidModeSwitchToMode unswapped.
This implements full swapping, including the pre-v2 version because how
could we have lived without that for so long...
SwapRestL is not technically needed but added for consistency with other
request handlers.
Co-Authored-by: Claude Code <noreply@anthropic.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2181>
The dispatch infrastructure already handles request length byte-swapping via
get_req_len() / client->req_len, so let's not double-swap the length
field back to the wrong byte order.
Co-Authored-by: Claude Code <noreply@anthropic.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2181>
ProcShmCreateSegment() sent the xShmCreateSegmentReply to the client
without byte-swapping the sequenceNumber field for byte-swapped clients.
Every other SHM Proc function that sends a reply (ProcShmQueryVersion,
ProcShmGetImage) correctly swaps the reply fields.
The sequenceNumber is a CARD16 that Xlib/XCB uses to match replies to
their corresponding requests. With a garbled sequence number, the client
library will mismatch the reply with the wrong request, causing the
client to hang waiting for the real reply, process stale data from a
different request's reply, or crash due to unexpected reply format.
Fix by adding byte-swap of sequenceNumber and length before
WriteToClient, consistent with the other SHM reply handlers.
Co-Authored-by: Claude Code <noreply@anthropic.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2181>
The CARD32 *value pointer was computed as (ptr + sizeof(rep))
BEFORE the NULL check for ptr. If AddFragment returns NULL, this
performs pointer arithmetic on a null pointer, which is undefined
behavior per C11 section 6.5.6 paragraph 8. With aggressive compiler
optimizations (e.g., GCC -O2 with LTO), the compiler could reason
that since ptr was used in arithmetic, it must be non-NULL, and
optimize away the NULL check entirely. This would then cause a
write to an invalid address on OOM.
Co-Authored-by: Claude Code <noreply@anthropic.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2181>
The byte-swap check for rep.spec.client used 'client->swapped'
(the queried client) instead of 'sendClient->swapped' (the
requesting client). The reply is sent to sendClient, so swapping
must be based on sendClient's byte order. When a byte-swapped
client queries a native-byte-order client (or vice versa), the
spec.client field in the reply has the wrong byte order, causing
the client library to misinterpret the XID. Lines 504 and later
correctly use sendClient->swapped, so this was an oversight.
Co-Authored-by: Claude Code <noreply@anthropic.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2181>
SProcXResQueryClientIds() swapped the numSpecs field but did not swap
the individual xXResClientIdSpec entries that follow the request header.
Each spec contains two CARD32 fields: client (an XID) and mask (a
bitmask selecting which client ID types to query).
Co-Authored-by: Claude Code <noreply@anthropic.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2181>
Only generate audit events for messages of the type avc (permission
denied) and error (e.g. invalid context).
For example avoid USER_SELINUX_ERR for policy load events:
audit[980]: USER_SELINUX_ERR pid=980 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xorg_t:s0 msg='avc: op=load_policy lsm=selinux seqno=8 res=1 exe="/usr/lib/xorg/Xorg" sauid=0 hostname=? addr=? terminal=?'
Signed-off-by: Christian Göttsche <cgzones@googlemail.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/801>
Re-map the SELinux security classes on policy loads, as the mapping will
be desynchronized (see man:selinux_set_mapping(3)) and audit messages
will not show the actual class and permission names:
USER_AVC pid=24283 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xorg_t:s0 msg='avc: denied { 0x10 } for request=XFIXES:SelectSelectionInput comm=/usr/bin/python3 resid=6400001 restype=WINDOW scontext=xuser_u:xuser_r:systemd_user_instance_generic_bin_t:s0 tcontext=xuser_u:object_r:xorg_t:s0 tclass=(null) permissive=1
In addition use type-safe assignments.
Signed-off-by: Christian Göttsche <cgzones@googlemail.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/801>
If there's nothing to send, skip over a bunch of code to make a list
that won't be used, and hopefully make the code path clearer to both
humans and static analyzers, who raise errors as seen in #1817 of
dereferencing NULL pointers when count == 0.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2072>
(cherry picked from commit d34243606c)
Reported in #1817:
xwayland-24.1.6/redhat-linux-build/../Xext/xres.c:233:13: warning[-Wanalyzer-possible-null-dereference]: dereference of possibly-NULL ‘current_clients’
xwayland-24.1.6/redhat-linux-build/../Xext/xres.c:228:23: acquire_memory: this call could return NULL
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2072>
(cherry picked from commit 3da60c96a9)
Reported in #1817:
xwayland-24.1.6/redhat-linux-build/../Xext/vidmode.c:96:5: warning[-Wanalyzer-null-argument]: use of NULL ‘VidModeCreateMode()’ where non-null expected
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2072>
(cherry picked from commit 5e62aaaf57)
Reported incorrectly in #1817 as:
xwayland-24.1.6/redhat-linux-build/../Xext/sync.c:2835:33: acquire_memory: allocated here
xwayland-24.1.6/redhat-linux-build/../Xext/sync.c:2843:12: danger: ‘priv’ leaks here; was allocated at [(30)](sarif:/runs/0/results/5/codeFlows/0/threadFlows/0/locations/29)
but the "leak" is really saving the pointer in an uninitalized pointer in
a structure that was already freed when the malloc of the SysCounterInfo
struct failed in SyncCreateSystemCounter(), because it returned the address
of the freed struct instead of NULL to indicate failure.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2072>
(cherry picked from commit 6034ce11b6)
Building with -Dxace=false was generating many failures of the form:
../dix/cursor.c: In function ‘AllocARGBCursor’:
../dix/cursor.c:281:10: error: implicit declaration of function
‘XaceHookResourceAccess’; did you mean ‘XaceHookPropertyAccess’?
[-Werror=implicit-function-declaration]
281 | rc = XaceHookResourceAccess(client, cid, X11_RESTYPE_CURSOR,
| ^~~~~~~~~~~~~~~~~~~~~~
| XaceHookPropertyAccess
Fixes: ae3c57333 ("xace: typesafe hook function for XACE_RESOURCE_ACCESS")
Fixes: 9524ffee8 ("xace: typesafe hook function for XACE_DEVICE_ACCESS")
Fixes: 67e468c8b ("xace: typesafe hook function for XACE_SEND_ACCESS")
Fixes: 3dfe00d5e ("xace: typesafe hook function for XACE_RECEIVE_ACCESS")
Fixes: 922b7685d ("xace: typesafe hook function for XACE_CLIENT_ACCESS")
Fixes: 0f6bb23bc ("xace: typesafe hook function for XACE_EXT_ACCESS")
Fixes: 47d6c3ad7 ("xace: typesafe hook function for XACE_SERVER_ACCESS")
Fixes: 51d8bcfc0 ("xace: typesafe hook function for XACE_SCREEN_ACCESS")
Fixes: 305f2d59d ("xace: typesafe hook function for XACE_SCREENSAVER_ACCESS")
Fixes: 591d95c79 ("xace: typesafe hook function for XACE_AUTH_AVAIL")
Fixes: facdaae4e ("xace: typesafe hook function for XACE_KEY_AVAIL")
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2056>
(cherry picked from commit 8bbf497e22)
Build breaks with gcc 14 & later when xf86bigfont is enabled:
../Xext/xf86bigfont.c: In function ‘XFree86BigfontExtensionInit’:
../Xext/xf86bigfont.c:709:28: error: implicit declaration of function
‘xfont2_allocate_font_private_index’;
did you mean ‘AllocateFontPrivateIndex’? [-Wimplicit-function-declaration]
709 | FontShmdescIndex = xfont2_allocate_font_private_index();
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| AllocateFontPrivateIndex
Fixes: 05a793f5b ("dix: Switch to the libXfont2 API (v2)")
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2053>
(cherry picked from commit 0617f6075b)
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>
(cherry picked from commit c285798984)
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>
(cherry picked from commit 8cbc90c881)
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>
(cherry picked from commit f52cea2f93)
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>
(cherry picked from commit 16a1242d0f)
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>
(cherry picked from commit fdb8c8ea41)
