commit 97f79ca01b6182e0ee987748fcdcbe276c84e0c9
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Tue Jun 17 14:50:22 2025 +0200

    xserver 21.1.17
    
    Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2025>

commit bb89548515a75d30399c3c9d7cae9f3706241808
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Mon Apr 28 14:59:46 2025 +0200

    xfree86: Check for RandR provider functions
    
    Changing XRandR provider properties if the driver has set no provider
    function such as the modesetting driver will cause a NULL pointer
    dereference and a crash of the Xorg server.
    
    Related to CVE-2025-49180
    
    This issue was discovered by Nils Emmerich <nemmerich@ernw.de> and
    reported by Julian Suleder via ERNW Vulnerability Disclosure.
    
    Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
    Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
    (cherry picked from commit 0235121c6a7a6eb247e2addb3b41ed6ef566853d)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2025>

commit 7c626aa63af274a347b91dd923027e715ed89023
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Tue May 20 15:18:19 2025 +0200

    randr: Check for overflow in RRChangeProviderProperty()
    
    A client might send a request causing an integer overflow when computing
    the total size to allocate in RRChangeProviderProperty().
    
    To avoid the issue, check that total length in bytes won't exceed the
    maximum integer value.
    
    CVE-2025-49180
    
    This issue was discovered by Nils Emmerich <nemmerich@ernw.de> and
    reported by Julian Suleder via ERNW Vulnerability Disclosure.
    
    Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
    Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
    (cherry picked from commit 3c3a4b767b16174d3213055947ea7f4f88e10ec6)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2025>

commit 8592cab6820f77c209c2ea9a7b94e0d4d1ac848c
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Mon Apr 28 11:47:15 2025 +0200

    record: Check for overflow in RecordSanityCheckRegisterClients()
    
    The RecordSanityCheckRegisterClients() checks for the request length,
    but does not check for integer overflow.
    
    A client might send a very large value for either the number of clients
    or the number of protocol ranges that will cause an integer overflow in
    the request length computation, defeating the check for request length.
    
    To avoid the issue, explicitly check the number of clients against the
    limit of clients (which is much lower than an maximum integer value) and
    the number of protocol ranges (multiplied by the record length) do not
    exceed the maximum integer value.
    
    This way, we ensure that the final computation for the request length
    will not overflow the maximum integer limit.
    
    CVE-2025-49179
    
    This issue was discovered by Nils Emmerich <nemmerich@ernw.de> and
    reported by Julian Suleder via ERNW Vulnerability Disclosure.
    
    Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
    Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
    (cherry picked from commit 2bde9ca49a8fd9a1e6697d5e7ef837870d66f5d4)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2025>

commit 7996ac60d81d665a87f4f736bcfe17e22a375b5c
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Mon Apr 28 10:46:03 2025 +0200

    os: Account for bytes to ignore when sharing input buffer
    
    When reading requests from the clients, the input buffer might be shared
    and used between different clients.
    
    If a given client sends a full request with non-zero bytes to ignore,
    the bytes to ignore may still be non-zero even though the request is
    full, in which case the buffer could be shared with another client who's
    request will not be processed because of those bytes to ignore, leading
    to a possible hang of the other client request.
    
    To avoid the issue, make sure we have zero bytes to ignore left in the
    input request when sharing the input buffer with another client.
    
    CVE-2025-49178
    
    This issue was discovered by Nils Emmerich <nemmerich@ernw.de> and
    reported by Julian Suleder via ERNW Vulnerability Disclosure.
    
    Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
    Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
    (cherry picked from commit d55c54cecb5e83eaa2d56bed5cc4461f9ba318c2)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2025>

commit 909ae2776815c6dc9dcba8b3c89b7ac507a9fc54
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Mon Apr 28 10:05:36 2025 +0200

    xfixes: Check request length for SetClientDisconnectMode
    
    The handler of XFixesSetClientDisconnectMode does not check the client
    request length.
    
    A client could send a shorter request and read data from a former
    request.
    
    Fix the issue by checking the request size matches.
    
    CVE-2025-49177
    
    This issue was discovered by Nils Emmerich <nemmerich@ernw.de> and
    reported by Julian Suleder via ERNW Vulnerability Disclosure.
    
    Fixes: e167299f6 - xfixes: Add ClientDisconnectMode
    Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
    Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
    (cherry picked from commit ab02fb96b1c701c3bb47617d965522c34befa6af)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2025>

commit f7dcf2d0d46d31735208c3270dc3457ea3093635
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Mon Apr 7 16:13:34 2025 +0200

    os: Do not overflow the integer size with BigRequest
    
    The BigRequest extension allows requests larger than the 16-bit length
    limit.
    
    It uses integers for the request length and checks for the size not to
    exceed the maxBigRequestSize limit, but does so after translating the
    length to integer by multiplying the given size in bytes by 4.
    
    In doing so, it might overflow the integer size limit before actually
    checking for the overflow, defeating the purpose of the test.
    
    To avoid the issue, make sure to check that the request size does not
    overflow the maxBigRequestSize limit prior to any conversion.
    
    The caller Dispatch() function however expects the return value to be in
    bytes, so we cannot just return the converted value in case of error, as
    that would also overflow the integer size.
    
    To preserve the existing API, we use a negative value for the X11 error
    code BadLength as the function only return positive values, 0 or -1 and
    update the caller Dispatch() function to take that case into account to
    return the error code to the offending client.
    
    CVE-2025-49176
    
    This issue was discovered by Nils Emmerich <nemmerich@ernw.de> and
    reported by Julian Suleder via ERNW Vulnerability Disclosure.
    
    Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
    Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
    (cherry picked from commit 03731b326a80b582e48d939fe62cb1e2b10400d9)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2025>

commit ea7b770952dbcf6c769db7538b55b4f92e1f95c5
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Fri Mar 28 09:43:52 2025 +0100

    render: Avoid 0 or less animated cursors
    
    Animated cursors use a series of cursors that the client can set.
    
    By default, the Xserver assumes at least one cursor is specified
    while a client may actually pass no cursor at all.
    
    That causes an out-of-bound read creating the animated cursor and a
    crash of the Xserver:
    
     | Invalid read of size 8
     |    at 0x5323F4: AnimCursorCreate (animcur.c:325)
     |    by 0x52D4C5: ProcRenderCreateAnimCursor (render.c:1817)
     |    by 0x52DC80: ProcRenderDispatch (render.c:1999)
     |    by 0x4A1E9D: Dispatch (dispatch.c:560)
     |    by 0x4B0169: dix_main (main.c:284)
     |    by 0x4287F5: main (stubmain.c:34)
     |  Address 0x59aa010 is 0 bytes after a block of size 0 alloc'd
     |    at 0x48468D3: reallocarray (vg_replace_malloc.c:1803)
     |    by 0x52D3DA: ProcRenderCreateAnimCursor (render.c:1802)
     |    by 0x52DC80: ProcRenderDispatch (render.c:1999)
     |    by 0x4A1E9D: Dispatch (dispatch.c:560)
     |    by 0x4B0169: dix_main (main.c:284)
     |    by 0x4287F5: main (stubmain.c:34)
     |
     | Invalid read of size 2
     |    at 0x5323F7: AnimCursorCreate (animcur.c:325)
     |    by 0x52D4C5: ProcRenderCreateAnimCursor (render.c:1817)
     |    by 0x52DC80: ProcRenderDispatch (render.c:1999)
     |    by 0x4A1E9D: Dispatch (dispatch.c:560)
     |    by 0x4B0169: dix_main (main.c:284)
     |    by 0x4287F5: main (stubmain.c:34)
     |  Address 0x8 is not stack'd, malloc'd or (recently) free'd
    
    To avoid the issue, check the number of cursors specified and return a
    BadValue error in both the proc handler (early) and the animated cursor
    creation (as this is a public function) if there is 0 or less cursor.
    
    CVE-2025-49175
    
    This issue was discovered by Nils Emmerich <nemmerich@ernw.de> and
    reported by Julian Suleder via ERNW Vulnerability Disclosure.
    
    Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
    Reviewed-by: José Expósito <jexposit@redhat.com>
    (cherry picked from commit 0885e0b26225c90534642fe911632ec0779eebee)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2025>

commit 2b287847622b0391c707d009e04205f889426516
Author: Alan Coopersmith <alan.coopersmith@oracle.com>
Date:   Sat May 31 15:06:23 2025 -0700

    XWin.man: fix typos in font change escapes
    
    Fixes warnings from `mandoc -T lint`:
    
    mandoc: XWin.man:332:28: WARNING: invalid escape sequence: \fp
    mandoc: XWin.man:397:1: WARNING: invalid escape sequence: \fX
    
    Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
    (cherry picked from commit 286578e83ed6519fb654547b70b6d9d58708f095)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2018>

commit 4430e87d09c07cab3be4074653c520871fcb63d6
Author: Alan Coopersmith <alan.coopersmith@oracle.com>
Date:   Mon Apr 14 18:41:33 2025 -0700

    Xserver.man: correct list of available authorization protocols
    
    XDM-AUTHORIZATION-2 (IPv6 capable version of -1) was never merged.
    MIT-KERBEROS-5 was removed by commit dfbe32b5b in 2007
    
    Fixes: dfbe32b5b ("Remove the old Kerberos 5 authentication code.")
    Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
    (cherry picked from commit 845c4ae5187f959fe042129e7c62210535f94290
     minus the removal of SUN-DES-1, which is still present in the 21.1-branch)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2018>

commit 30c3dac8a0ddf2f7cfbd4d0d887910f73763643b
Author: Alan Coopersmith <alan.coopersmith@oracle.com>
Date:   Mon Apr 14 15:56:34 2025 -0700

    Xserver.man: add Xwayland(1) to list of server-specific man pages
    
    Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
    (cherry picked from commit 80ad8a2c6d6e5d2d1861ce71d3b5dc5df15ea96a)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2018>

commit 7d8608ff0596d26d441f0ca8f7b71587c1ee77cd
Author: Alan Coopersmith <alan.coopersmith@oracle.com>
Date:   Sat Mar 29 13:27:33 2025 -0700

    Xserver.man: remove X FireWall Proxy (xfwp) info
    
    xfwp has not been maintained in many years, with ssh X11-Forwarding
    preferred instead.
    
    Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
    (cherry picked from commit b4b6b19c9a834df980e9209f1c44318fd67f3e8a)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2018>

commit c0f6ef9f078de90a904c12c877511a0263d7930e
Author: Tanguy Ortolo <tanguy+debian@ortolo.eu>
Date:   Tue Jul 29 13:32:07 2014 +0200

    xorg.conf.man: Complete the xorg.conf.5 manpage with Option "Disable"
    
    The xorg.conf.5 manpage mentions an "Enable" option to enable a monitor
    regardless of whether or not it is connected, but gives no indication of how
    to disable it. This patch corrects that by documenting the "Disable" option.
    
    Orignally from: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755809
    
    Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
    (cherry picked from commit e4d2de81980666757580366e597455f5d2d43889)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2018>

commit a3a37c56998e85ac2ab98d3a3778c312fc0e8fad
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Thu Mar 20 10:37:53 2025 +1000

    dix: pick the right keyboard for focus FollowKeyboard
    
    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: f01ee198ff0c ("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 cab9017485566da656b12b686e571d42b0f28afb)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1894>

commit 0249e717d4cbc40559d6072655d5a873320cb085
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Thu Mar 20 11:24:32 2025 +1000

    dix: fix erroneous BUG_RETURN check
    
    Check was inverted, we want to complain if evcount exceeds our target
    array.
    
    Fixes: 219c54b8a333 ("dix: fix DeviceStateNotify event calculation")
    (cherry picked from commit 2bca68f41b222ca7bf881f0e2d7011e9fea43c60)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1894>

commit 7be648c5055adcefb55164c626d4d1e931189557
Author: Alan Coopersmith <alan.coopersmith@oracle.com>
Date:   Sat Mar 8 16:29:53 2025 -0800

    dix-config.h: define HAVE_STRUCT_SOCKADDR_STORAGE for xtrans 1.6
    
    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 4b5d410591ed29afba010cd30594d8ed7c195c2e)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1894>

commit 3a60fe79d3cf192eb878cfafefdf27938cc61e71
Author: Alan Coopersmith <alan.coopersmith@oracle.com>
Date:   Sat Mar 8 14:49:16 2025 -0800

    pkgconfig files: Add URL
    
    https://github.com/pkgconf/pkgconf/blob/master/man/pc.5 says it's
    a mandatory field in *.pc files.
    
    Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
    (cherry picked from commit b73cd6066af1dde94e66c5593290b78a96d10dc0)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1894>

commit bf37ce8edc252beb4aa2c6b942c86672f5bb2815
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Thu Mar 6 09:40:22 2025 +1000

    Xi: disallow grabbing disabled devices
    
    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 797f63b8be1693a7c0ae5df8b76911d804959ce5)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1894>

commit fca017cd1a96794b6b5fe4f8a0635b7b3730e771
Author: Enrico Weigelt, metux IT consult <info@metux.net>
Date:   Fri Feb 28 14:41:12 2025 +0100

    xfree86: xf86helper: fix NULL dereference
    
    xf86MatchDevice() can segfault if screensecptr->device is NULL.
    
    Issue: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1767
    Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
    (cherry picked from commit fe9c911e22cb0b24e01a8183af1634149675261d)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1894>

commit 8b699feb9de9c88bef8a8b31cdd3683e1abdd664
Author: Alan Coopersmith <alan.coopersmith@oracle.com>
Date:   Sun Oct 8 13:22:13 2023 -0700

    xkb: Add tbGetBufferString helper function
    
    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 42a1f25faff612641dffb95a77f9ec3661111875)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1894>

commit 8cf8d80f7c209f34522e11eeb8e5556f54ebc544
Author: Martin Burggraf <TSO@gmx.net>
Date:   Thu Aug 13 21:16:40 2015 +0200

    xkb: correcting mathematical nonsense in XkbGeomFPText
    
    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 7a23010232312c24cde6070a50dbb5433ce52a59)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1894>

commit 971d57c77d57ddfa03ef24d51e919220de3f918a
Author: Alan Coopersmith <alan.coopersmith@oracle.com>
Date:   Sat Feb 22 16:15:01 2025 -0800

    xkb: Convert more sprintf calls to snprintf in xkbtext.c
    
    Based on xorg/lib/libxkbfile@390acfe5bb88cdab509b5eaae4041f265e969d2b
    
    Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
    (cherry picked from commit 60419d8e4a02dc2599351b65b3503f0bb0932eaa)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1894>

commit a2dc81508908424e92b3db0e720e7bb1eb54a13e
Author: José Expósito <jexposit@redhat.com>
Date:   Tue Apr 30 17:37:39 2024 +0200

    xkb: Check that needed is > 0 in XkbResizeKeyActions
    
    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 6d3383418672dd87e6cd73931268fcbacdaae9c8)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1894>

commit 1e52c5c09418671cbd5c0beb4856e449a755cecc
Author: Alan Coopersmith <alan.coopersmith@oracle.com>
Date:   Sat Feb 22 10:02:20 2025 -0800

    xkb: ensure XkbAllocNames sets num_rg to 0 on allocation failure
    
    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 09c6f09eb77a306f44490a9af0751e77cc9d1530)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1894>

commit f71114570fc1b1dda97423198575ea2a0cbed19f
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Mon Feb 10 10:49:24 2025 +1000

    mi: guard miPointer functions against NULL dereferences
    
    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 68c17477d29937e081c482a343a942d5bd41c4ee)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1894>

commit 4530321f5abf2f1f46c521079d095c42e0b1978d
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Fri Feb 7 18:14:55 2025 +1000

    mi: don't crash on miPointerGetPosition for disabled devices
    
    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 acbdd0ecddc18d9fa7fc1634d4daf868ee0cd755)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1894>

commit ba830583e6a8e9a78f09e2d723813c03142b11f6
Author: tholin <thomas.lindroth@gmail.com>
Date:   Tue Jan 4 12:08:11 2022 +0000

    dix: Hold input lock for AttachDevice()
    
    Fix the following race:
    
    Possible data race during read of size 8 at 0xA112510 by thread #6
    Locks held: 1, at address 0x366B40
       at 0x14C8B9: GetMaster (devices.c:2691)
       by 0x15CFC5: IsFloating (events.c:346)
       by 0x2B9554: miPointerGetScreen (mipointer.c:527)
       by 0x1A5136: xf86PostButtonEventM (xf86Xinput.c:1379)
       by 0x1A52BD: xf86PostButtonEvent (xf86Xinput.c:1345)
       by 0x485F45B: EvdevProcessEvent (in /usr/lib64/xorg/modules/input/evdev_drv.so)
       by 0x485FDAC: EvdevReadInput (in /usr/lib64/xorg/modules/input/evdev_drv.so)
       by 0x195427: xf86ReadInput (xf86Events.c:247)
       by 0x2CC113: InputReady (inputthread.c:180)
       by 0x2CE4EA: ospoll_wait (ospoll.c:657)
       by 0x2CC077: InputThreadDoWork (inputthread.c:369)
       by 0x484A336: mythread_wrapper (hg_intercepts.c:406)
    
    This conflicts with a previous write of size 8 by thread #1
    Locks held: none
       at 0x14D2C6: AttachDevice (devices.c:2609)
       by 0x15CF85: ReattachToOldMaster (events.c:1457)
       by 0x1647DD: DeactivateKeyboardGrab (events.c:1700)
       by 0x25D7F1: ProcXIUngrabDevice (xigrabdev.c:169)
       by 0x2552AD: ProcIDispatch (extinit.c:398)
       by 0x155291: Dispatch (dispatch.c:479)
       by 0x158CBA: dix_main (main.c:276)
       by 0x143A3D: main (stubmain.c:34)
     Address 0xa112510 is 336 bytes inside a block of size 904 alloc'd
       at 0x4846571: calloc (vg_replace_malloc.c:1328)
       by 0x14A0B3: AddInputDevice (devices.c:260)
       by 0x1A31A0: xf86ActivateDevice (xf86Xinput.c:365)
       by 0x1A4549: xf86NewInputDevice (xf86Xinput.c:948)
       by 0x1A4B44: NewInputDeviceRequest (xf86Xinput.c:1090)
       by 0x1B81FE: device_added (udev.c:282)
       by 0x1B8516: config_udev_init (udev.c:439)
       by 0x1B7091: config_init (config.c:50)
       by 0x197970: InitInput (xf86Init.c:814)
       by 0x158C6B: dix_main (main.c:250)
       by 0x143A3D: main (stubmain.c:34)
     Block was alloc'd by thread #1
    
    The steps to trigger the race are:
    1. Main thread does cleanup at mipointer.c:360 setting the slave device's
       miPointerPtr to null.
    2. Input thread use MIPOINTER in mipointer.c and get the slave's
       miPointerPtr = null.
    3. Main thread updates dev->master at devices.c:2609.
    4. MIPOINTER would now return the master's miPointerPtr but the input
       thread already got the slave's miPointerPtr in step 2 and segfaults by
       null ptr deref.
    
    Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1260
    Signed-off-by: Thomas Lindroth <thomas.lindroth@gmail.com>
    (cherry picked from commit dc7cb45482cea6ccec22d117ca0b489500b4d0a0)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1874>

commit b7f84e6d509c004a7abb514af75b94cb907d451b
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Tue Feb 25 15:38:07 2025 +0100

    xserver 21.1.16
    
    Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1830>

commit a2c0f84c1cd0c92918f08f83f562c2e324cd4cbb
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Mon Jan 20 17:10:31 2025 +0100

    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>
    (cherry picked from commit c285798984c6bb99e454a33772cde23d394d3dcd)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1830>

commit 043a4e959b8590ff37b72cd3440328ec3e39699f
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Mon Jan 20 17:06:07 2025 +0100

    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>
    (cherry picked from commit 8cbc90c8817306af75a60f494ec9dbb1061e50db)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1830>

commit 330b4068212c02548b53d19c0078ddc75c36a724
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Mon Jan 20 16:54:30 2025 +0100

    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>
    (cherry picked from commit f52cea2f93a0c891494eb3334894442a92368030)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1830>

commit e708ad021753d603580d314c48b93d3adf459c5f
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Mon Jan 20 16:52:01 2025 +0100

    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>
    (cherry picked from commit 16a1242d0ffc7f45ed3c595ee7564b5c04287e0b)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1830>

commit 826cef825fe49a275deb28e85b8c714b697f5efa
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Mon Dec 16 16:18:04 2024 +0100

    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>
    (cherry picked from commit 6e0f332ba4c8b8c9a9945dc9d7989bfe06f80e14)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1830>

commit d09125fbb3b997ed77b7f008f8bd30328ba69fbb
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Mon Jan 13 16:09:43 2025 +0100

    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>
    (cherry picked from commit b07192a8bedb90b039dc0f70ae69daf047ff9598)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1830>

commit 7169628a1715f8203665f9805c714ed111907914
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Tue Dec 17 15:19:45 2024 +0100

    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>
    (cherry picked from commit c1ff84bef2569b4ba4be59323cf575d1798ba9be)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1830>

commit 32decb1efb89341881de8266f3dd1c3356981bfd
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Mon Dec 16 11:25:11 2024 +0100

    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>
    (cherry picked from commit bba9df1a9d57234c76c0b93f88dacb143d01bca2)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1830>

commit 8cb23fac62e05d7340e320b2db0dd3e8538d1fba
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Thu Nov 28 14:09:04 2024 +0100

    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>
    (cherry picked from commit 0e4ed94952b255c04fe910f6a1d9c852878dcd64)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1830>

commit b4293650b50efe7832cf9eac71217ad8d6341e02
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Thu Nov 28 11:49:34 2024 +0100

    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>
    (cherry picked from commit 80d69f01423fc065c950e1ff4e8ddf9f675df773)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1830>

commit ea526ccb20d222196494b2adf9da52dab68a8997
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Wed Nov 27 14:41:45 2024 +0100

    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>
    (cherry picked from commit 11fcda8753e994e15eb915d28cf487660ec8e722)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1830>

commit 5f0c4e0bf254c8b4552da276d01b1b80881b4e26
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Wed Dec 4 15:49:43 2024 +1000

    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.
    
