Accepting request 1248777 from X11:XOrg

OBS-URL: https://build.opensuse.org/request/show/1248777
OBS-URL: https://build.opensuse.org/package/show/openSUSE:Factory/xwayland?expand=0&rev=41

U_CVE-2025-26594-0001-Cursor-Refuse-to-free-the-root-cursor.patch

@@ -1,49 +0,0 @@
-From efca605c45ff51b57f136222b966ce1d610ebc33 Mon Sep 17 00:00:00 2001
-From: Olivier Fourdan <ofourdan@redhat.com>
-Date: Wed, 27 Nov 2024 11:27:05 +0100
-Subject: [PATCH xserver 1/2] Cursor: Refuse to free the root cursor
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-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>
----
- dix/dispatch.c | 4 ++++
- 1 file changed, 4 insertions(+)
-
-Index: xwayland-24.1.4/dix/dispatch.c
-===================================================================
---- xwayland-24.1.4.orig/dix/dispatch.c
-+++ xwayland-24.1.4/dix/dispatch.c
-@@ -3106,6 +3106,10 @@ ProcFreeCursor(ClientPtr client)
-     rc = dixLookupResourceByType((void **) &pCursor, stuff->id, RT_CURSOR,
-                                  client, DixDestroyAccess);
-     if (rc == Success) {
-+        if (pCursor == rootCursor) {
-+            client->errorValue = stuff->id;
-+            return BadCursor;
-+        }
-         FreeResource(stuff->id, RT_NONE);
-         return Success;
-     }

U_CVE-2025-26594-0002-dix-keep-a-ref-to-the-rootCursor.patch

@@ -1,43 +0,0 @@
-From ded614e74e7175927dd2bc5ef69accaf2de29939 Mon Sep 17 00:00:00 2001
-From: Peter Hutterer <peter.hutterer@who-t.net>
-Date: Wed, 4 Dec 2024 15:49:43 +1000
-Subject: [PATCH xserver 2/2] dix: keep a ref to the rootCursor
-
-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>
----
- dix/main.c | 4 ++++
- 1 file changed, 4 insertions(+)
-
-Index: xwayland-24.1.4/dix/main.c
-===================================================================
---- xwayland-24.1.4.orig/dix/main.c
-+++ xwayland-24.1.4/dix/main.c
-@@ -234,6 +234,8 @@ dix_main(int argc, char *argv[], char *e
-             FatalError("could not open default cursor font");
-         }
- 
-+        rootCursor = RefCursor(rootCursor);
-+
- #ifdef PANORAMIX
-         /*
-          * Consolidate window and colourmap information for each screen
-@@ -274,6 +276,8 @@ dix_main(int argc, char *argv[], char *e
- 
-         Dispatch();
- 
-+        UnrefCursor(rootCursor);
-+
-         UndisplayDevices();
-         DisableAllDevices();
- 

U_CVE-2025-26595-0001-xkb-Fix-buffer-overflow-in-XkbVModMaskText.patch

@@ -1,57 +0,0 @@
-From 98602942c143075ab7464f917e0fc5d31ce28c3f Mon Sep 17 00:00:00 2001
-From: Olivier Fourdan <ofourdan@redhat.com>
-Date: Wed, 27 Nov 2024 14:41:45 +0100
-Subject: [PATCH xserver] xkb: Fix buffer overflow in XkbVModMaskText()
-
-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>
----
- xkb/xkbtext.c | 16 ++++++++--------
- 1 file changed, 8 insertions(+), 8 deletions(-)
-
-Index: xwayland-24.1.4/xkb/xkbtext.c
-===================================================================
---- xwayland-24.1.4.orig/xkb/xkbtext.c
-+++ xwayland-24.1.4/xkb/xkbtext.c
-@@ -174,14 +174,14 @@ XkbVModMaskText(XkbDescPtr xkb,
-                 len = strlen(tmp) + 1 + (str == buf ? 0 : 1);
-                 if (format == XkbCFile)
-                     len += 4;
--                if ((str - (buf + len)) <= VMOD_BUFFER_SIZE) {
--                    if (str != buf) {
--                        if (format == XkbCFile)
--                            *str++ = '|';
--                        else
--                            *str++ = '+';
--                        len--;
--                    }
-+                if ((str - buf) + len > VMOD_BUFFER_SIZE)
-+                    continue; /* Skip */
-+                if (str != buf) {
-+                    if (format == XkbCFile)
-+                        *str++ = '|';
-+                    else
-+                        *str++ = '+';
-+                    len--;
-                 }
-                 if (format == XkbCFile)
-                     sprintf(str, "%sMask", tmp);

U_CVE-2025-26596-0001-xkb-Fix-computation-of-XkbSizeKeySyms.patch

@@ -1,41 +0,0 @@
-From b41f6fce201e77a174550935330e2f7772d4adf9 Mon Sep 17 00:00:00 2001
-From: Olivier Fourdan <ofourdan@redhat.com>
-Date: Thu, 28 Nov 2024 11:49:34 +0100
-Subject: [PATCH xserver] xkb: Fix computation of XkbSizeKeySyms
-
-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>
----
- xkb/xkb.c | 8 ++++----
- 1 file changed, 4 insertions(+), 4 deletions(-)
-
-Index: xwayland-24.1.4/xkb/xkb.c
-===================================================================
---- xwayland-24.1.4.orig/xkb/xkb.c
-+++ xwayland-24.1.4/xkb/xkb.c
-@@ -1092,10 +1092,10 @@ XkbSizeKeySyms(XkbDescPtr xkb, xkbGetMap
-     len = rep->nKeySyms * SIZEOF(xkbSymMapWireDesc);
-     symMap = &xkb->map->key_sym_map[rep->firstKeySym];
-     for (i = nSyms = 0; i < rep->nKeySyms; i++, symMap++) {
--        if (symMap->offset != 0) {
--            nSymsThisKey = XkbNumGroups(symMap->group_info) * symMap->width;
--            nSyms += nSymsThisKey;
--        }
-+        nSymsThisKey = XkbNumGroups(symMap->group_info) * symMap->width;
-+        if (nSymsThisKey == 0)
-+            continue;
-+        nSyms += nSymsThisKey;
-     }
-     len += nSyms * 4;
-     rep->totalSyms = nSyms;

U_CVE-2025-26597-0001-xkb-Fix-buffer-overflow-in-XkbChangeTypesOfKey.patch

@@ -1,38 +0,0 @@
-From c5114475db18f29d639537d60e135bdfc11a5d3a Mon Sep 17 00:00:00 2001
-From: Olivier Fourdan <ofourdan@redhat.com>
-Date: Thu, 28 Nov 2024 14:09:04 +0100
-Subject: [PATCH xserver] xkb: Fix buffer overflow in XkbChangeTypesOfKey()
-
-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>
----
- xkb/XKBMisc.c | 1 +
- 1 file changed, 1 insertion(+)
-
-Index: xwayland-24.1.4/xkb/XKBMisc.c
-===================================================================
---- xwayland-24.1.4.orig/xkb/XKBMisc.c
-+++ xwayland-24.1.4/xkb/XKBMisc.c
-@@ -552,6 +552,7 @@ XkbChangeTypesOfKey(XkbDescPtr xkb,
-         i = XkbSetNumGroups(i, 0);
-         xkb->map->key_sym_map[key].group_info = i;
-         XkbResizeKeySyms(xkb, key, 0);
-+        XkbResizeKeyActions(xkb, key, 0);
-         return Success;
-     }
- 

U_CVE-2025-26598-0001-Xi-Fix-barrier-device-search.patch

@@ -1,112 +0,0 @@
-From 0f5ea9d269ac6225bcb302a1ec0f58878114da9f Mon Sep 17 00:00:00 2001
-From: Olivier Fourdan <ofourdan@redhat.com>
-Date: Mon, 16 Dec 2024 11:25:11 +0100
-Subject: [PATCH xserver] Xi: Fix barrier device search
-
-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>
----
- Xi/xibarriers.c | 27 +++++++++++++++++++++++----
- 1 file changed, 23 insertions(+), 4 deletions(-)
-
-Index: xwayland-24.1.4/Xi/xibarriers.c
-===================================================================
---- xwayland-24.1.4.orig/Xi/xibarriers.c
-+++ xwayland-24.1.4/Xi/xibarriers.c
-@@ -129,14 +129,15 @@ static void FreePointerBarrierClient(str
- 
- static struct PointerBarrierDevice *GetBarrierDevice(struct PointerBarrierClient *c, int deviceid)
- {
--    struct PointerBarrierDevice *pbd = NULL;
-+    struct PointerBarrierDevice *p, *pbd = NULL;
- 
--    xorg_list_for_each_entry(pbd, &c->per_device, entry) {
--        if (pbd->deviceid == deviceid)
-+    xorg_list_for_each_entry(p, &c->per_device, entry) {
-+        if (p->deviceid == deviceid) {
-+            pbd = p;
-             break;
-+        }
-     }
- 
--    BUG_WARN(!pbd);
-     return pbd;
- }
- 
-@@ -337,6 +338,9 @@ barrier_find_nearest(BarrierScreenPtr cs
-         double distance;
- 
-         pbd = GetBarrierDevice(c, dev->id);
-+        if (!pbd)
-+            continue;
-+
-         if (pbd->seen)
-             continue;
- 
-@@ -445,6 +449,9 @@ input_constrain_cursor(DeviceIntPtr dev,
-         nearest = &c->barrier;
- 
-         pbd = GetBarrierDevice(c, master->id);
-+        if (!pbd)
-+            continue;
-+
-         new_sequence = !pbd->hit;
- 
-         pbd->seen = TRUE;
-@@ -485,6 +492,9 @@ input_constrain_cursor(DeviceIntPtr dev,
-         int flags = 0;
- 
-         pbd = GetBarrierDevice(c, master->id);
-+        if (!pbd)
-+            continue;
-+
-         pbd->seen = FALSE;
-         if (!pbd->hit)
-             continue;
-@@ -679,6 +689,9 @@ BarrierFreeBarrier(void *data, XID id)
-             continue;
- 
-         pbd = GetBarrierDevice(c, dev->id);
-+        if (!pbd)
-+            continue;
-+
-         if (!pbd->hit)
-             continue;
- 
-@@ -738,6 +751,8 @@ static void remove_master_func(void *res
-     barrier = container_of(b, struct PointerBarrierClient, barrier);
- 
-     pbd = GetBarrierDevice(barrier, *deviceid);
-+    if (!pbd)
-+        return;
- 
-     if (pbd->hit) {
-         BarrierEvent ev = {
-@@ -903,6 +918,10 @@ ProcXIBarrierReleasePointer(ClientPtr cl
-         barrier = container_of(b, struct PointerBarrierClient, barrier);
- 
-         pbd = GetBarrierDevice(barrier, dev->id);
-+        if (!pbd) {
-+            client->errorValue = dev->id;
-+            return BadDevice;
-+        }
- 
-         if (pbd->barrier_event_id == event_id)
-             pbd->release_event_id = event_id;

U_CVE-2025-26599-0001-composite-Handle-failure-to-redirect-in-compRedirect.patch

@@ -1,59 +0,0 @@
-From 10a24e364ac15983051d0bb90817c88bbe107036 Mon Sep 17 00:00:00 2001
-From: Olivier Fourdan <ofourdan@redhat.com>
-Date: Tue, 17 Dec 2024 15:19:45 +0100
-Subject: [PATCH xserver 1/2] composite: Handle failure to redirect in
- compRedirectWindow()
-
-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>
----
- composite/compalloc.c | 5 +++--
- 1 file changed, 3 insertions(+), 2 deletions(-)
-
-Index: xwayland-24.1.4/composite/compalloc.c
-===================================================================
---- xwayland-24.1.4.orig/composite/compalloc.c
-+++ xwayland-24.1.4/composite/compalloc.c
-@@ -140,6 +140,7 @@ compRedirectWindow(ClientPtr pClient, Wi
-     CompScreenPtr cs = GetCompScreen(pWin->drawable.pScreen);
-     WindowPtr pLayerWin;
-     Bool anyMarked = FALSE;
-+    int status = Success;
- 
-     if (pWin == cs->pOverlayWin) {
-         return Success;
-@@ -218,13 +219,13 @@ compRedirectWindow(ClientPtr pClient, Wi
- 
-     if (!compCheckRedirect(pWin)) {
-         FreeResource(ccw->id, RT_NONE);
--        return BadAlloc;
-+        status = BadAlloc;
-     }
- 
-     if (anyMarked)
-         compHandleMarkedWindows(pWin, pLayerWin);
- 
--    return Success;
-+    return status;
- }
- 
- void

U_CVE-2025-26599-0002-composite-initialize-border-clip-even-when-pixmap-al.patch

@@ -1,121 +0,0 @@
-From f5ce639ff9d3af05e79efce6c51e084352d28ed1 Mon Sep 17 00:00:00 2001
-From: Olivier Fourdan <ofourdan@redhat.com>
-Date: Mon, 13 Jan 2025 16:09:43 +0100
-Subject: [PATCH xserver 2/2] composite: initialize border clip even when
- pixmap alloc fails
-
-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>
----
- composite/compalloc.c | 11 ++++++++---
- 1 file changed, 8 insertions(+), 3 deletions(-)
-
-Index: xwayland-24.1.4/composite/compalloc.c
-===================================================================
---- xwayland-24.1.4.orig/composite/compalloc.c
-+++ xwayland-24.1.4/composite/compalloc.c
-@@ -606,9 +606,12 @@ compAllocPixmap(WindowPtr pWin)
-     int h = pWin->drawable.height + (bw << 1);
-     PixmapPtr pPixmap = compNewPixmap(pWin, x, y, w, h);
-     CompWindowPtr cw = GetCompWindow(pWin);
-+    Bool status;
- 
--    if (!pPixmap)
--        return FALSE;
-+    if (!pPixmap) {
-+        status = FALSE;
-+        goto out;
-+    }
-     if (cw->update == CompositeRedirectAutomatic)
-         pWin->redirectDraw = RedirectDrawAutomatic;
-     else
-@@ -622,14 +625,16 @@ compAllocPixmap(WindowPtr pWin)
-         DamageRegister(&pWin->drawable, cw->damage);
-         cw->damageRegistered = TRUE;
-     }
-+    status = TRUE;
- 
-+out:
-     /* Make sure our borderClip is up to date */
-     RegionUninit(&cw->borderClip);
-     RegionCopy(&cw->borderClip, &pWin->borderClip);
-     cw->borderClipX = pWin->drawable.x;
-     cw->borderClipY = pWin->drawable.y;
- 
--    return TRUE;
-+    return status;
- }
- 
- void

U_CVE-2025-26600-0001-dix-Dequeue-pending-events-on-frozen-device-on-remov.patch

@@ -1,61 +0,0 @@
-From 70ad5d36ae80f6e5a436eabfee642c2c013e51cc Mon Sep 17 00:00:00 2001
-From: Olivier Fourdan <ofourdan@redhat.com>
-Date: Mon, 16 Dec 2024 16:18:04 +0100
-Subject: [PATCH xserver] dix: Dequeue pending events on frozen device on
- removal
-
-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>
----
- dix/devices.c | 18 ++++++++++++++++++
- 1 file changed, 18 insertions(+)
-
-Index: xwayland-24.1.4/dix/devices.c
-===================================================================
---- xwayland-24.1.4.orig/dix/devices.c
-+++ xwayland-24.1.4/dix/devices.c
-@@ -981,6 +981,23 @@ FreeAllDeviceClasses(ClassesPtr classes)
- 
- }
- 
-+static void
-+FreePendingFrozenDeviceEvents(DeviceIntPtr dev)
-+{
-+    QdEventPtr qe, tmp;
-+
-+    if (!dev->deviceGrab.sync.frozen)
-+        return;
-+
-+    /* Dequeue any frozen pending events */
-+    xorg_list_for_each_entry_safe(qe, tmp, &syncEvents.pending, next) {
-+        if (qe->device == dev) {
-+            xorg_list_del(&qe->next);
-+            free(qe);
-+        }
-+    }
-+}
-+
- /**
-  * Close down a device and free all resources.
-  * Once closed down, the driver will probably not expect you that you'll ever
-@@ -1045,6 +1062,7 @@ CloseDevice(DeviceIntPtr dev)
-         valuator_mask_free(&dev->last.touches[j].valuators);
-     free(dev->last.touches);
-     dev->config_info = NULL;
-+    FreePendingFrozenDeviceEvents(dev);
-     dixFreePrivates(dev->devPrivates, PRIVATE_DEVICE);
-     free(dev);
- }

U_CVE-2025-26601-0001-sync-Do-not-let-sync-objects-uninitialized.patch

@@ -1,66 +0,0 @@
-From 573a2265aacfeaddcc1bb001905a6f7d4fa15ee6 Mon Sep 17 00:00:00 2001
-From: Olivier Fourdan <ofourdan@redhat.com>
-Date: Mon, 20 Jan 2025 16:52:01 +0100
-Subject: [PATCH xserver 1/4] sync: Do not let sync objects uninitialized
-
-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>
----
- Xext/sync.c | 13 ++++++++-----
- 1 file changed, 8 insertions(+), 5 deletions(-)
-
-diff --git a/Xext/sync.c b/Xext/sync.c
-index b6417b3b0..4267d3af6 100644
---- a/Xext/sync.c
-+++ b/Xext/sync.c
-@@ -330,11 +330,6 @@ SyncInitTrigger(ClientPtr client, SyncTrigger * pTrigger, XID syncObject,
-             client->errorValue = syncObject;
-             return rc;
-         }
--        if (pSync != pTrigger->pSync) { /* new counter for trigger */
--            SyncDeleteTriggerFromSyncObject(pTrigger);
--            pTrigger->pSync = pSync;
--            newSyncObject = TRUE;
--        }
-     }
- 
-     /* if system counter, ask it what the current value is */
-@@ -402,6 +397,14 @@ SyncInitTrigger(ClientPtr client, SyncTrigger * pTrigger, XID syncObject,
-         }
-     }
- 
-+    if (changes & XSyncCACounter) {
-+        if (pSync != pTrigger->pSync) { /* new counter for trigger */
-+            SyncDeleteTriggerFromSyncObject(pTrigger);
-+            pTrigger->pSync = pSync;
-+            newSyncObject = TRUE;
-+        }
-+    }
-+
-     /*  we wait until we're sure there are no errors before registering
-      *  a new counter on a trigger
-      */
--- 
-2.48.1
-

U_CVE-2025-26601-0002-sync-Check-values-before-applying-changes.patch

@@ -1,80 +0,0 @@
-From 7dc3f11abb51cad8a59ecbff5278c8c8a318df41 Mon Sep 17 00:00:00 2001
-From: Olivier Fourdan <ofourdan@redhat.com>
-Date: Mon, 20 Jan 2025 16:54:30 +0100
-Subject: [PATCH xserver 2/4] sync: Check values before applying changes
-
-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>
----
- Xext/sync.c | 36 ++++++++++++++++++------------------
- 1 file changed, 18 insertions(+), 18 deletions(-)
-
-diff --git a/Xext/sync.c b/Xext/sync.c
-index 4267d3af6..4eab5a6ac 100644
---- a/Xext/sync.c
-+++ b/Xext/sync.c
-@@ -351,6 +351,24 @@ SyncInitTrigger(ClientPtr client, SyncTrigger * pTrigger, XID syncObject,
-         }
-     }
- 
-+    if (changes & (XSyncCAValueType | XSyncCAValue)) {
-+        if (pTrigger->value_type == XSyncAbsolute)
-+            pTrigger->test_value = pTrigger->wait_value;
-+        else {                  /* relative */
-+            Bool overflow;
-+
-+            if (pCounter == NULL)
-+                return BadMatch;
-+
-+            overflow = checked_int64_add(&pTrigger->test_value,
-+                                         pCounter->value, pTrigger->wait_value);
-+            if (overflow) {
-+                client->errorValue = pTrigger->wait_value >> 32;
-+                return BadValue;
-+            }
-+        }
-+    }
-+
-     if (changes & XSyncCATestType) {
- 
-         if (pSync && SYNC_FENCE == pSync->type) {
-@@ -379,24 +397,6 @@ SyncInitTrigger(ClientPtr client, SyncTrigger * pTrigger, XID syncObject,
-         }
-     }
- 
--    if (changes & (XSyncCAValueType | XSyncCAValue)) {
--        if (pTrigger->value_type == XSyncAbsolute)
--            pTrigger->test_value = pTrigger->wait_value;
--        else {                  /* relative */
--            Bool overflow;
--
--            if (pCounter == NULL)
--                return BadMatch;
--
--            overflow = checked_int64_add(&pTrigger->test_value,
--                                         pCounter->value, pTrigger->wait_value);
--            if (overflow) {
--                client->errorValue = pTrigger->wait_value >> 32;
--                return BadValue;
--            }
--        }
--    }
--
-     if (changes & XSyncCACounter) {
-         if (pSync != pTrigger->pSync) { /* new counter for trigger */
-             SyncDeleteTriggerFromSyncObject(pTrigger);
--- 
-2.48.1
-

U_CVE-2025-26601-0003-sync-Do-not-fail-SyncAddTriggerToSyncObject.patch

@@ -1,47 +0,0 @@
-From 4ccaa5134482b6be9c9a7f0b66cd221ef325d082 Mon Sep 17 00:00:00 2001
-From: Olivier Fourdan <ofourdan@redhat.com>
-Date: Mon, 20 Jan 2025 17:06:07 +0100
-Subject: [PATCH xserver 3/4] sync: Do not fail SyncAddTriggerToSyncObject()
-
-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>
----
- Xext/sync.c | 7 +++----
- 1 file changed, 3 insertions(+), 4 deletions(-)
-
-diff --git a/Xext/sync.c b/Xext/sync.c
-index 4eab5a6ac..c36de1a2e 100644
---- a/Xext/sync.c
-+++ b/Xext/sync.c
-@@ -200,8 +200,8 @@ SyncAddTriggerToSyncObject(SyncTrigger * pTrigger)
-             return Success;
-     }
- 
--    if (!(pCur = malloc(sizeof(SyncTriggerList))))
--        return BadAlloc;
-+    /* Failure is not an option, it's succeed or burst! */
-+    pCur = XNFalloc(sizeof(SyncTriggerList));
- 
-     pCur->pTrigger = pTrigger;
-     pCur->next = pTrigger->pSync->pTriglist;
-@@ -409,8 +409,7 @@ SyncInitTrigger(ClientPtr client, SyncTrigger * pTrigger, XID syncObject,
-      *  a new counter on a trigger
-      */
-     if (newSyncObject) {
--        if ((rc = SyncAddTriggerToSyncObject(pTrigger)) != Success)
--            return rc;
-+        SyncAddTriggerToSyncObject(pTrigger);
-     }
-     else if (pCounter && IsSystemCounter(pCounter)) {
-         SyncComputeBracketValues(pCounter);
--- 
-2.48.1
-

U_CVE-2025-26601-0004-sync-Apply-changes-last-in-SyncChangeAlarmAttributes.patch

@@ -1,128 +0,0 @@
-From f0984082067f79b45383fa1eb889c6a901667331 Mon Sep 17 00:00:00 2001
-From: Olivier Fourdan <ofourdan@redhat.com>
-Date: Mon, 20 Jan 2025 17:10:31 +0100
-Subject: [PATCH xserver 4/4] sync: Apply changes last in
- SyncChangeAlarmAttributes()
-
-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>
----
- Xext/sync.c | 42 +++++++++++++++++++++++++++---------------
- 1 file changed, 27 insertions(+), 15 deletions(-)
-
-diff --git a/Xext/sync.c b/Xext/sync.c
-index c36de1a2e..e282e6657 100644
---- a/Xext/sync.c
-+++ b/Xext/sync.c
-@@ -800,8 +800,14 @@ SyncChangeAlarmAttributes(ClientPtr client, SyncAlarm * pAlarm, Mask mask,
-     int status;
-     XSyncCounter counter;
-     Mask origmask = mask;
-+    SyncTrigger trigger;
-+    Bool select_events_changed = FALSE;
-+    Bool select_events_value;
-+    int64_t delta;
- 
--    counter = pAlarm->trigger.pSync ? pAlarm->trigger.pSync->id : None;
-+    trigger = pAlarm->trigger;
-+    delta = pAlarm->delta;
-+    counter = trigger.pSync ? trigger.pSync->id : None;
- 
-     while (mask) {
-         int index2 = lowbit(mask);
-@@ -817,24 +823,24 @@ SyncChangeAlarmAttributes(ClientPtr client, SyncAlarm * pAlarm, Mask mask,
-         case XSyncCAValueType:
-             mask &= ~XSyncCAValueType;
-             /* sanity check in SyncInitTrigger */
--            pAlarm->trigger.value_type = *values++;
-+            trigger.value_type = *values++;
-             break;
- 
-         case XSyncCAValue:
-             mask &= ~XSyncCAValue;
--            pAlarm->trigger.wait_value = ((int64_t)values[0] << 32) | values[1];
-+            trigger.wait_value = ((int64_t)values[0] << 32) | values[1];
-             values += 2;
-             break;
- 
-         case XSyncCATestType:
-             mask &= ~XSyncCATestType;
-             /* sanity check in SyncInitTrigger */
--            pAlarm->trigger.test_type = *values++;
-+            trigger.test_type = *values++;
-             break;
- 
-         case XSyncCADelta:
-             mask &= ~XSyncCADelta;
--            pAlarm->delta = ((int64_t)values[0] << 32) | values[1];
-+            delta = ((int64_t)values[0] << 32) | values[1];
-             values += 2;
-             break;
- 
-@@ -844,10 +850,8 @@ SyncChangeAlarmAttributes(ClientPtr client, SyncAlarm * pAlarm, Mask mask,
-                 client->errorValue = *values;
-                 return BadValue;
-             }
--            status = SyncEventSelectForAlarm(pAlarm, client,
--                                             (Bool) (*values++));
--            if (status != Success)
--                return status;
-+            select_events_value = (Bool) (*values++);
-+            select_events_changed = TRUE;
-             break;
- 
-         default:
-@@ -856,25 +860,33 @@ SyncChangeAlarmAttributes(ClientPtr client, SyncAlarm * pAlarm, Mask mask,
-         }
-     }
- 
-+    if (select_events_changed) {
-+        status = SyncEventSelectForAlarm(pAlarm, client, select_events_value);
-+        if (status != Success)
-+            return status;
-+    }
-+
-     /* "If the test-type is PositiveComparison or PositiveTransition
-      *  and delta is less than zero, or if the test-type is
-      *  NegativeComparison or NegativeTransition and delta is
-      *  greater than zero, a Match error is generated."
-      */
-     if (origmask & (XSyncCADelta | XSyncCATestType)) {
--        if ((((pAlarm->trigger.test_type == XSyncPositiveComparison) ||
--              (pAlarm->trigger.test_type == XSyncPositiveTransition))
--             && pAlarm->delta < 0)
-+        if ((((trigger.test_type == XSyncPositiveComparison) ||
-+              (trigger.test_type == XSyncPositiveTransition))
-+             && delta < 0)
-             ||
--            (((pAlarm->trigger.test_type == XSyncNegativeComparison) ||
--              (pAlarm->trigger.test_type == XSyncNegativeTransition))
--             && pAlarm->delta > 0)
-+            (((trigger.test_type == XSyncNegativeComparison) ||
-+              (trigger.test_type == XSyncNegativeTransition))
-+             && delta > 0)
-             ) {
-             return BadMatch;
-         }
-     }
- 
-     /* postpone this until now, when we're sure nothing else can go wrong */
-+    pAlarm->delta = delta;
-+    pAlarm->trigger = trigger;
-     if ((status = SyncInitTrigger(client, &pAlarm->trigger, counter, RTCounter,
-                                   origmask & XSyncCAAllTrigger)) != Success)
-         return status;
--- 
-2.48.1
-

xwayland-24.1.0.tar.xz

@@ -1,3 +0,0 @@
-version https://git-lfs.github.com/spec/v1
-oid sha256:bef21c4f18807a4ed571c4e2df60ab63b5466bbd502ecceb2485b892ab76dcc2
-size 1301180

xwayland-24.1.1.tar.xz

@@ -1,3 +0,0 @@
-version https://git-lfs.github.com/spec/v1
-oid sha256:7125bee0b10335805d7f5ba57dfaa359a7850af1a68524f1d97b362741a51832
-size 1301652

xwayland-24.1.3.tar.xz

@@ -1,3 +0,0 @@
-version https://git-lfs.github.com/spec/v1
-oid sha256:dcdb57a66cc9b124c8f936760592628ac4e744a7d7b3179aa86189ad7ea4cb10
-size 1302164

xwayland-24.1.5.tar.xz

@@ -1,3 +0,0 @@
-version https://git-lfs.github.com/spec/v1
-oid sha256:cb4bd170e6fa6b545ba0567be8f693d2eeccfc62d04c67037dd14f06daad361d
-size 1302484