Reported in #1817:
xwayland-24.1.6/redhat-linux-build/../glamor/glamor_render.c:1577:21:
warning[-Wanalyzer-null-dereference]: dereference of NULL ‘0’
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2094>
(cherry picked from commit 6a4ec30af4)
(cherry picked from commit 2df83c5566)
Reported in #1817:
xwayland-24.1.6/redhat-linux-build/../glamor/glamor_dash.c:152:10:
warning[-Wanalyzer-null-dereference]: dereference of NULL ‘0’
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2094>
(cherry picked from commit c6522229b8)
(cherry picked from commit 84dccbc45a)
We know that if gc->tileIsPixel is false, then gc->tile.pixmap must be
a valid pixmap, but gcc's static analyzer doesn't and needs to be told.
Silences false positive reported in #1817:
xwayland-24.1.6/redhat-linux-build/../glamor/glamor_core.c:205:19:
warning[-Wanalyzer-null-dereference]: dereference of NULL ‘0’
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2094>
(cherry picked from commit a79bdc495e)
(cherry picked from commit 03b40ee38d)
Unlike GetPictureScreen(), GetPictureScreenIfSet() checks if the
private key is registered, and returns NULL if it is not.
Reported in #1817:
xwayland-24.1.6/redhat-linux-build/../glamor/glamor.c:926:5:
warning[-Wanalyzer-null-dereference]: dereference of NULL ‘ps’
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2094>
(cherry picked from commit 69b48423bd)
(cherry picked from commit 394cb2d824)
CI meson-disable-options builds were failing with:
../hw/xwayland/xwayland-screen.c: In function ‘xwl_close_screen’:
../hw/xwayland/xwayland-screen.c:246:5: error: implicit declaration of
function ‘XaceDeleteCallback’; did you mean ‘DeleteCallback’?
[-Werror=implicit-function-declaration]
246 | XaceDeleteCallback(XACE_PROPERTY_ACCESS, xwl_access_property_callback, screen);
| ^~~~~~~~~~~~~~~~~~
| DeleteCallback
../hw/xwayland/xwayland-screen.c:246:24: error: ‘XACE_PROPERTY_ACCESS’
undeclared (first use in this function)
246 | XaceDeleteCallback(XACE_PROPERTY_ACCESS, xwl_access_property_callback, screen);
| ^~~~~~~~~~~~~~~~~~~~
../hw/xwayland/xwayland-screen.c: In function ‘xwl_screen_init’:
../hw/xwayland/xwayland-screen.c:1174:5: error: implicit declaration of
function ‘XaceRegisterCallback’ [-Werror=implicit-function-declaration]
1174 | XaceRegisterCallback(XACE_PROPERTY_ACCESS, xwl_access_property_callback, pScreen);
| ^~~~~~~~~~~~~~~~~~~~
../hw/xwayland/xwayland-screen.c:1174:26: error: ‘XACE_PROPERTY_ACCESS’
undeclared (first use in this function)
1174 | XaceRegisterCallback(XACE_PROPERTY_ACCESS, xwl_access_property_callback, pScreen);
| ^~~~~~~~~~~~~~~~~~~~
Fixes: a07c2cda9 ("xwayland: Add an XACE property access handler")
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2056>
(cherry picked from commit 48acd1ae78)
(cherry picked from commit 3298b0a3e0)
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)
(cherry picked from commit 5a1fe4e4f1)
In most typical Linux X servers (like Xvfb, Xephyr, or Xwayland),
no child process outlives the server, so this issue rarely arises.
However, in embedded X servers (based on Xvfb or Kdrive) or in
custom Xorg modules, the server might launch a long-running command
with regular fork+exec calls. If the X server crashes or exits while
that command is still running (for example, it spawns a tombstone
generator or any process that hangs or turns to zombie), the file
descriptor associated with the abstract socket can remain open in the
child process. This leads to the kernel refusing to allow another X
server to bind the same socket until the child process terminates
(because there is no explicit way to unlink abstract socket, unlike
Unix socket). By marking the file descriptor as close-on-exec, we
ensure it is automatically closed in child processes, preserving the
ability of a new X server process to bind the socket immediately.
Signed-off-by: Twaik Yont <9674930+twaik@users.noreply.github.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1906>
(cherry picked from commit 5568b0f83f)
(cherry picked from commit 59673c0503)
Xwayland has its own XYToWindow() handler to account for the case when
the pointer leaves an X11 surface to enter another Wayland native
window.
When that occurs, Xwayland will treat it as if the pointer had entered
the root window so that the X11 clients receive an appropriate leave
event.
When the pointer leaves the X11 surface, Xwayland will call
CheckMotion() to update the sprite coordinates and possibly the cursor.
However, if we left the surface with a button down, it means the wayland
compositor has grabbed the pointer so we will not get button release
events from the compositor.
Once the button is released, Xwayland will get a pointer enter event from
the compositor, and Xwayland will clear up the buttons pressed.
But that might confuse Xwayland in thinking the pointer has crossed the
windows and leave the wrong cursor showing in the X11 surface.
To avoid the issue, if buttons are down, do not pretend the cursor has
left the X11 surface for the root window.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1811
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2008>
(cherry picked from commit 8cb078f8b6)
(cherry picked from commit 3c80595c7e)
This fixes a crash when we try to send focus events and dereference
FollowKeyboardWin (0x3) as WindowPtr.
A device set to XSetDeviceFocus(FollowKeyboard) is supposed to follow
the focus of the corresponding master device. During ActivateKeyboard
a slave device is detached from the master for the duration for the grab
so we don't actually have a master to follow - leaving our oldWin set to
the FollowKeyboardWin constant. This later crashes when we try to
dereference it.
Fix this by getting the current master (if any), or the saved master (if
temporarily detached due to a grab). And if failing that, use the VCK
as fallback device - that is technically wrong but it's such a niche use
case that it shouldn't matter.
Reproducer:
window = XCreateSimpleWindow(...)
deviceid = any device that is IsXExtensionKeyboard device
XSetDeviceFocus(deviceid, FollowKeyboard, ...)
XGrabDevice(deviceid, window, ...)
Fixes: f01ee198ff ("dix: don't use inputInfo.keyboard to get the focus window in ActivateKbdGrab")
Found-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Tested-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit cab9017485)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1895>
xtrans 1.6 will use struct sockaddr_storage if HAVE_STRUCT_SOCKADDR_STORAGE
is defined, even if IPv6 is disabled, unlike previous versions which tied
it to the IPv6 #define.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
(cherry picked from commit 4b5d410591)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1895>
Grabbing a disabled (pointer) device will lead to a segfault later
in the myriad of places where we look at the device's spriteInfo - which
will be NULL.
As a workaround, disallow grabbing a disabled device by pretending it's
already grabbed. Since the point of a grab is to receive all events by
that device and disabled devices cannot send events, this should be Good
Enough.
Tested-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit 797f63b8be)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1895>
Handles common case of allocating & copying string to temporary buffer
(cherry picked from xorg/lib/libxkbfile@8a91517ca6ea77633476595b0eb5b213357c60e5)
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
(cherry picked from commit 42a1f25faf)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1895>
Fixes formatting of negative numbers, so they don't show minus sign
after the decimal point.
(cherry picked from xorg/lib/libxkbfile@d2ec504fec2550f4fd046e801b34317ef4a4bab9)
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
(cherry picked from commit 7a23010232)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1895>
Passing a negative value in `needed` to the `XkbResizeKeyActions()`
function can create a `newActs` array of an unespected size.
Check the value and return if it is invalid.
This error has been found by a static analysis tool. This is the report:
Error: OVERRUN (CWE-119):
libX11-1.8.7/src/xkb/XKBMAlloc.c:811: cond_const:
Checking "xkb->server->size_acts == 0" implies that
"xkb->server->size_acts" is 0 on the true branch.
libX11-1.8.7/src/xkb/XKBMAlloc.c:811: buffer_alloc:
"calloc" allocates 8 bytes dictated by parameters
"(size_t)((xkb->server->size_acts == 0) ? 1 : xkb->server->size_acts)"
and "8UL".
libX11-1.8.7/src/xkb/XKBMAlloc.c:811: var_assign:
Assigning: "newActs" = "calloc((size_t)((xkb->server->size_acts == 0) ? 1 : xkb->server->size_acts), 8UL)".
libX11-1.8.7/src/xkb/XKBMAlloc.c:815: assignment:
Assigning: "nActs" = "1".
libX11-1.8.7/src/xkb/XKBMAlloc.c:829: cond_at_least:
Checking "nCopy > 0" implies that "nCopy" is at least 1 on the
true branch.
libX11-1.8.7/src/xkb/XKBMAlloc.c:830: overrun-buffer-arg:
Overrunning buffer pointed to by "&newActs[nActs]" of 8 bytes by
passing it to a function which accesses it at byte offset 15
using argument "nCopy * 8UL" (which evaluates to 8).
# 828|
# 829| if (nCopy > 0)
# 830|-> memcpy(&newActs[nActs], XkbKeyActionsPtr(xkb, i),
# 831| nCopy * sizeof(XkbAction));
# 832| if (nCopy < nKeyActs)
(cherry picked from xorg/lib/libx11@af1312d2873d2ce49b18708a5029895aed477392)
Signed-off-by: José Expósito <jexposit@redhat.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
(cherry picked from commit 6d33834186)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1895>
If there was a previous radio_groups array which we failed to realloc
and freed instead, clear the array size in the XkbNamesRec.
Taken from xorg/lib/libx11@258a8ced681dc1bc50396be7439fce23f9807e2a
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
(cherry picked from commit 09c6f09eb7)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1895>
Already in place for some functions, let's add it to most others.
The only function missing is miPointerSetPosition() which needs to
return the ScreenPtr and that one is unclear if we don't have a screen -
returning NULL will crash the caller(s) so let's wait for something to
trigger this bug before we try to fix it wrongly.
Related to #1782
(cherry picked from commit 68c17477d2)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1895>
If a device is disabled, its master device is forcibly reset to NULL but
unlike a floating device it doesn't have a sprite allocated. Calling
miPointerGetPosition for a disabled device thus crashes.
Avoid this by returning 0/0 for any device without a miPointer.
This is a quick fix only, a proper fix for this issue is rather more
involved.
Closes#1782
(cherry picked from commit acbdd0ecdd)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1895>
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>
(cherry picked from commit c285798984)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1831>
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>
(cherry picked from commit 8cbc90c881)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1831>
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>
(cherry picked from commit f52cea2f93)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1831>
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>
(cherry picked from commit 16a1242d0f)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1831>
When a device is removed while still frozen, the events queued for that
device remain while the device itself is freed.
As a result, replaying the events will cause a use after free.
To avoid the issue, make sure to dequeue and free any pending events on
a frozen device when removed.
CVE-2025-26600, ZDI-CAN-25871
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>
(cherry picked from commit 6e0f332ba4)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1831>
If it fails to allocate the pixmap, the function compAllocPixmap() would
return early and leave the borderClip region uninitialized, which may
lead to the use of uninitialized value as reported by valgrind:
Conditional jump or move depends on uninitialised value(s)
at 0x4F9B33: compClipNotify (compwindow.c:317)
by 0x484FC9: miComputeClips (mivaltree.c:476)
by 0x48559A: miValidateTree (mivaltree.c:679)
by 0x4F0685: MapWindow (window.c:2693)
by 0x4A344A: ProcMapWindow (dispatch.c:922)
by 0x4A25B5: Dispatch (dispatch.c:560)
by 0x4B082A: dix_main (main.c:282)
by 0x429233: main (stubmain.c:34)
Uninitialised value was created by a heap allocation
at 0x4841866: malloc (vg_replace_malloc.c:446)
by 0x4F47BC: compRedirectWindow (compalloc.c:171)
by 0x4FA8AD: compCreateWindow (compwindow.c:592)
by 0x4EBB89: CreateWindow (window.c:925)
by 0x4A2E6E: ProcCreateWindow (dispatch.c:768)
by 0x4A25B5: Dispatch (dispatch.c:560)
by 0x4B082A: dix_main (main.c:282)
by 0x429233: main (stubmain.c:34)
Conditional jump or move depends on uninitialised value(s)
at 0x48EEDBC: pixman_region_translate (pixman-region.c:2233)
by 0x4F9255: RegionTranslate (regionstr.h:312)
by 0x4F9B7E: compClipNotify (compwindow.c:319)
by 0x484FC9: miComputeClips (mivaltree.c:476)
by 0x48559A: miValidateTree (mivaltree.c:679)
by 0x4F0685: MapWindow (window.c:2693)
by 0x4A344A: ProcMapWindow (dispatch.c:922)
by 0x4A25B5: Dispatch (dispatch.c:560)
by 0x4B082A: dix_main (main.c:282)
by 0x429233: main (stubmain.c:34)
Uninitialised value was created by a heap allocation
at 0x4841866: malloc (vg_replace_malloc.c:446)
by 0x4F47BC: compRedirectWindow (compalloc.c:171)
by 0x4FA8AD: compCreateWindow (compwindow.c:592)
by 0x4EBB89: CreateWindow (window.c:925)
by 0x4A2E6E: ProcCreateWindow (dispatch.c:768)
by 0x4A25B5: Dispatch (dispatch.c:560)
by 0x4B082A: dix_main (main.c:282)
by 0x429233: main (stubmain.c:34)
Conditional jump or move depends on uninitialised value(s)
at 0x48EEE33: UnknownInlinedFun (pixman-region.c:2241)
by 0x48EEE33: pixman_region_translate (pixman-region.c:2225)
by 0x4F9255: RegionTranslate (regionstr.h:312)
by 0x4F9B7E: compClipNotify (compwindow.c:319)
by 0x484FC9: miComputeClips (mivaltree.c:476)
by 0x48559A: miValidateTree (mivaltree.c:679)
by 0x4F0685: MapWindow (window.c:2693)
by 0x4A344A: ProcMapWindow (dispatch.c:922)
by 0x4A25B5: Dispatch (dispatch.c:560)
by 0x4B082A: dix_main (main.c:282)
by 0x429233: main (stubmain.c:34)
Uninitialised value was created by a heap allocation
at 0x4841866: malloc (vg_replace_malloc.c:446)
by 0x4F47BC: compRedirectWindow (compalloc.c:171)
by 0x4FA8AD: compCreateWindow (compwindow.c:592)
by 0x4EBB89: CreateWindow (window.c:925)
by 0x4A2E6E: ProcCreateWindow (dispatch.c:768)
by 0x4A25B5: Dispatch (dispatch.c:560)
by 0x4B082A: dix_main (main.c:282)
by 0x429233: main (stubmain.c:34)
Fix compAllocPixmap() to initialize the border clip even if the creation
of the backing pixmap has failed, to avoid depending later on
uninitialized border clip values.
Related to CVE-2025-26599, ZDI-CAN-25851
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit b07192a8be)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1831>
The function compCheckRedirect() may fail if it cannot allocate the
backing pixmap.
In that case, compRedirectWindow() will return a BadAlloc error.
However that failure code path will shortcut the validation of the
window tree marked just before, which leaves the validate data partly
initialized.
That causes a use of uninitialized pointer later.
The fix is to not shortcut the call to compHandleMarkedWindows() even in
the case of compCheckRedirect() returning an error.
CVE-2025-26599, ZDI-CAN-25851
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit c1ff84bef2)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1831>
The function GetBarrierDevice() would search for the pointer device
based on its device id and return the matching value, or supposedly NULL
if no match was found.
Unfortunately, as written, it would return the last element of the list
if no matching device id was found which can lead to out of bounds
memory access.
Fix the search function to return NULL if not matching device is found,
and adjust the callers to handle the case where the device cannot be
found.
CVE-2025-26598, ZDI-CAN-25740
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>
(cherry picked from commit bba9df1a9d)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1831>
If XkbChangeTypesOfKey() is called with nGroups == 0, it will resize the
key syms to 0 but leave the key actions unchanged.
If later, the same function is called with a non-zero value for nGroups,
this will cause a buffer overflow because the key actions are of the wrong
size.
To avoid the issue, make sure to resize both the key syms and key actions
when nGroups is 0.
CVE-2025-26597, ZDI-CAN-25683
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>
(cherry picked from commit 0e4ed94952)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1831>
The computation of the length in XkbSizeKeySyms() differs from what is
actually written in XkbWriteKeySyms(), leading to a heap overflow.
Fix the calculation in XkbSizeKeySyms() to match what kbWriteKeySyms()
does.
CVE-2025-26596, ZDI-CAN-25543
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>
(cherry picked from commit 80d69f0142)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1831>
The code in XkbVModMaskText() allocates a fixed sized buffer on the
stack and copies the virtual mod name.
There's actually two issues in the code that can lead to a buffer
overflow.
First, the bound check mixes pointers and integers using misplaced
parenthesis, defeating the bound check.
But even though, if the check fails, the data is still copied, so the
stack overflow will occur regardless.
Change the logic to skip the copy entirely if the bound check fails.
CVE-2025-26595, ZDI-CAN-25545
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>
(cherry picked from commit 11fcda8753)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1831>
CreateCursor returns a cursor with refcount 1 - that refcount is used by
the resource system, any caller needs to call RefCursor to get their own
reference. That happens correctly for normal cursors but for our
rootCursor we keep a variable to the cursor despite not having a ref for
ourselves.
Fix this by reffing/unreffing the rootCursor to ensure our pointer is
valid.
Related to CVE-2025-26594, ZDI-CAN-25544
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit b0a09ba602)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1831>
If a cursor reference count drops to 0, the cursor is freed.
The root cursor however is referenced with a specific global variable,
and when the root cursor is freed, the global variable may still point
to freed memory.
Make sure to prevent the rootCursor from being explicitly freed by a
client.
CVE-2025-26594, ZDI-CAN-25544
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
v2: Explicitly forbid XFreeCursor() on the root cursor (Peter Hutterer
<peter.hutterer@who-t.net>)
v3: Return BadCursor instead of BadValue (Michel Dänzer
<michel@daenzer.net>)
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Suggested-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 01642f263f)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1831>
The xsync test is relying on the values being changed even in the case
of a BadMatch value.
Typically, it updates the delta but does not update the test type
comparison, so when passing a negative value, it generates a BadMatch.
That's actually not correct, and that will fail with the new fixes that
check the validity of the values prior to apply the changes.
Fix the test by updating the test type as needed.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit 05e54fefaf)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1831>
The cleanup function for GBM is called on the various error paths.
Once xwl_glamor_gbm_cleanup() has been called, GBM support is no longer
usable (and the corresponding data structures are freed), so there is
no way we can keep using GLAMOR after that point.
Make sure to explicitly disable GLAMOR support in that case, so we do
not crash later on trying to use GBM.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit e8784b7d89)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1766>
Consider the following keymap:
```xkb
xkb_keymap {
xkb_keycodes {
<compose> = 135;
};
xkb_symbols {
key <compose> {
[ SetGroup(group = +1) ]
};
};
};
```
When the user presses the compose key, the following happens:
1. The compositor forwards the key to Xwayland.
2. Xwayland executes the SetGroup action and sets the base_group to 1
and the effective group to 1.
3. The compositor updates its own state and sends the effective group,
1, to Xwayland.
4. Xwayland sets the locked group to 1 and the effective group to
1 + 1 = 2.
This is wrong since pressing compose should set the effective group to 1
but to X applications the effective group appears to be 2.
This commit makes it so that Xwayland completely ignores the key
behaviors and actions of the keymap and only updates the modifier and
group components in response to the wayland modifiers events.
Signed-off-by: Julian Orth <ju.orth@gmail.com>
(cherry picked from commit 45c1d22ff6)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1766>
