commit 7dbd8d0dd1929c2011009fd1770c8aa470df97fb
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Tue Nov 10 14:10:53 2026 +0100

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

commit a11d070e4ea78c6c97a7e88c57277d766cd9050b
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Fri Oct 2 15:58:58 2026 +0200

    Xv: reject negative image size in QueryImageAttributes
    
    When ddQueryImageAttributes() overflows and returns a negative size,
    QueryImageAttributes would still reply with that value cast to CARD32,
    reporting a bogus data_size to the client.
    
    Reject negative sizes with BadValue.
    
    CVE-2026-109903
    
    Reported-by: Tristan Madani <tristan@talencesecurity.com>
    Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
    Assisted-by: AI
    
    (cherry picked from commit bddd1a6ad91cacc34af773c8c913f205c3917847)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2390>

commit 1376ac1f0edad6bd44dc6db3b4e49370a60d8e2f
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Fri Oct 2 15:58:45 2026 +0200

    Xv: reject negative image size in PutImage
    
    ddQueryImageAttributes() can return a negative size when the
    adaptor overflows during size calculation. Adding that value to
    the request header size can make the length check accept a request
    that does not contain the claimed image data.
    
    Reject negative sizes before validating the request length.
    
    CVE-2026-109096
    
    Reported-by: Tristan Madani <tristan@talencesecurity.com>
    Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
    Assisted-by: AI
    
    (cherry picked from commit 59bef99381b33c3a3d21fe6835d2aaf28d1597b0)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2390>

commit 99e647e914d947a791e92253a071955a9703647a
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Fri Oct 2 15:58:36 2026 +0200

    glamor: prevent overflow in Xv image size calculation
    
    glamor_xv_query_image_attributes() computed image sizes with 32-bit
    signed ints. Large CARD16 width/height values (especially for NV12
    and YV12/I420) wrap the result, so protocol length checks can accept
    requests that lack the required image payload.
    
    Compute sizes with 64-bit arithmetic and return -1 when the result
    does not fit in int, so callers can reject the request.
    
    CVE-2026-109095
    
    Reported-by: Tristan Madani <tristan@talencesecurity.com>
    Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
    Assisted-by: AI
    
    (cherry picked from commit 1a84c543e70d4e3482875a234a9cb53d63339606)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2390>

commit a59678e491a762e504829cac069cf37f4ccafe0d
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Fri Oct 2 15:42:42 2026 +0200

    XRes: prevent overflow in resource bytes swap path
    
    SProcXResQueryResourceBytes multiplied numSpecs by the spec size
    before REQUEST_FIXED_SIZE without an overflow check.
    
    On 32-bit servers, a large numSpecs can wrap, pass length validation,
    and walk the swap loop past the request buffer.
    
    Reject numSpecs values that would cause an overflow before validating
    or swapping the array, matching ProcXResQueryResourceBytes.
    
    CVE-2026-109094
    
    Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
    Assisted-by: AI
    
    (cherry picked from commit a77de3094e9e29661efff00876b06f2f97e0bf3f)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2390>

commit a3899d75e180d73f2971af2a402e6fdf19c0339c
Author: Acts1631 <acts1631kjv@proton.me>
Date:   Tue Jul 21 12:13:56 2026 -0400

    XRes: prevent overflow in client ID request size
    
    On 32-bit servers, a QueryClientIds request can overflow
    numSpecs * sizeof(xXResClientIdSpec) before REQUEST_FIXED_SIZE
    checks it. A small request with a large numSpecs can therefore
    pass validation and drive the normal or swapped handler past
    the request buffer.
    
    Reject numSpecs values that cannot be represented in the
    request-size calculation before validating or accessing the array.
    
    CVE-2026-109904
    
    (cherry picked from commit f7b5749315445334029a3e0dc953bd2646ee694b)
    (cherry picked from commit 6330d2f8effe9a63d354879b332340730765b7d5)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2390>

commit 99ce069ae814b39048543062e073320f14723ee0
Author: Acts1631 <acts1631kjv@proton.me>
Date:   Tue Jul 21 11:32:24 2026 -0400

    XTest: validate valuator range before writing
    
    XTestFakeInput copied device valuators into a fixed stack array before
    checking whether the record fit in the target device axis range. A
    high-axis device and crafted request could write past the array.
    
    Validate the count and range before indexing the stack array.
    
    CVE-2026-109093
    
    (cherry picked from commit 43b4064af332fdd8cfc52709b7b584724a68401d)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2390>

commit a4d7800f0f56469a082e3755bfa6b148c707075c
Author: Acts1631 <acts1631kjv@proton.me>
Date:   Tue Jul 21 10:57:50 2026 -0400

    Xv: prevent overflow in shared-memory bounds check
    
    A crafted XvShmPutImage offset could wrap the image-size addition
    before range validation and pass an invalid source pointer to the DDX.
    
    Reject negative image sizes and validate the offset and required range
    with subtraction before deriving the source pointer.
    
    CVE-2026-109092
    
    (cherry picked from commit 71cba5e407b22241b9078b61350a5f6631d2c59b)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2390>

commit 56e4ab6e8d94222480c8d7a28f530334059e3ab7
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Tue Oct 6 12:01:45 2026 +0200

    test: cover EDID DS_RANGES overflow of hsync/vrefresh arrays
    
    Drive xf86EdidMonitorSet() with a crafted EDID that has more Display-Range
    descriptors than MAX_HSYNC/MAX_VREFRESH. Extra ranges must be dropped
    instead of overflowing MonRec.
    
    Related to CVE-2026-109091
    
    Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
    Assisted-by: AI
    
    (cherry picked from commit 4aba5440efcfe36175fa7b944281135f275f7cf7)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2390>

commit d88f0f7fdb2834c24feca63c0af5f46a57f4a04c
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Fri Oct 2 15:02:54 2026 +0200

    xfree86: bound EDID DS_RANGES against hsync/vrefresh array size
    
    handle_detailed_monset() records Display-Range (DS_RANGES) descriptors
    from EDID into the fixed-size MonRec hsync[] and vrefresh[] arrays
    without checking nHsync / nVrefresh against MAX_HSYNC / MAX_VREFRESH.
    
    A malicious EDID with more DS_RANGES descriptors than the array
    capacity (base block plus CEA extension detailed slots) overruns those
    arrays and clobbers adjacent MonRec members such as Modes, Last, and
    DDC, leading to an out-of-bounds write and subsequent crash.
    
    Clamp each store the same way the xorg.conf path already does, and
    drop extra descriptors while still applying maxPixClock.
    
    CVE-2026-109091
    
    Reported-by: Eun0us / Espilon <eun0us@espilon.net>
    Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
    Assisted-by: AI
    
    (cherry picked from commit 95cf222d43c9d58ae84ace27651eb60809594898)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2390>

commit 0fb6041ca1e887d91a79ea9641b8838dfbf7ab06
Author: Matt Turner <mattst88@gmail.com>
Date:   Wed Oct 21 21:00:21 2026 -0400

    meson: use the right cpu family name for 32-bit x86 in int10
    
    Meson calls 32-bit x86 'x86', not 'i386', so since 71c7824e8 ("meson:
    check cpu_family() instead of cpu()") int10 is built without -D_PC on
    32-bit x86, and x86emu there runs without the real interrupt vectors
    or system BIOS. Before that, cpu() returned values like 'i686' on most
    systems, so the check rarely matched either.
    
    Fixes: 71c7824e8 ("meson: check cpu_family() instead of cpu()")
    Signed-off-by: Matt Turner <mattst88@gmail.com>
    (cherry picked from commit ecdaca33a7fd435e6fef14e14e9d01ccabdeea10)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2378>

commit 74314086fe538531b53ceb04c024d1e083b6a9ee
Author: Alan Coopersmith <alan.coopersmith@oracle.com>
Date:   Sat Oct 17 14:31:30 2026 -0700

    xkb: fix typo in sizeof expression
    
    XkbExtensionDeviceNotify is an int (#define'd to 11)
    xkbExtensionDeviceNotify is a typedef for a struct, and is used
    in sizeof in all the other memset calls in this file.
    
    Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
    (cherry picked from commit 0c69071611585ccd04d226143b81a3065a497633)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2378>

commit 8ffcbd09cd2605ef514b9eead28b03dea9626ff4
Author: Alan Coopersmith <alan.coopersmith@oracle.com>
Date:   Thu Oct 8 17:53:59 2026 -0700

    Xi: fix event_id & time delta in generated barrier events
    
    The fix for CVE-2026-93519 moved the updates of pbd->last_timestamp
    and pbd->barrier_event_id from after they were used to generate the
    data in events to before, causing the event_id to be one too high,
    and the time delta (ms - pbd->last_timestamp) to always be zero.
    
    This fix moves them back to being after they are used to generate
    the event data.
    
    Fixes: 1f42cc1f ("Xi: add bounds check for barrier events in input_constrain_cursor")
    Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
    (cherry picked from commit 98aed9ddba7b42d2a46fcc1f343f4b392967b838)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2378>

commit 4a1a50b532cbcd742dd0228e51c74dc38bd239b4
Author: Alan Coopersmith <alan.coopersmith@oracle.com>
Date:   Thu Oct 8 17:17:20 2026 -0700

    Xi: avoid memory leak when hitting bounds check for barrier events
    
    The fix for CVE-2026-93519 added a bounds check for barrier events in
    CreatePointerBarrierClient() and if it's hit immediately returns
    BadAlloc.  Unfortunately it was added after `ret` was already allocated
    and before *client_out is set to `ret`, so `ret` leaks.
    
    This fix changes it to jump to the same cleanup code to free(ret)
    that the rest of the function already uses.
    
    Fixes: 1f42cc1f0 ("Xi: add bounds check for barrier events in input_constrain_cursor")
    Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
    (cherry picked from commit 8e901e6013803a94b25020bde384dd17966564eb)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2378>

commit 59d09692e508d95012547376784e522519716502
Author: Matt Turner <mattst88@gmail.com>
Date:   Wed Oct 21 20:44:00 2026 -0400

    meson: don't build the int10 helpers for the stub backend
    
    With int10=stub, meson builds helper_exec.c, helper_mem.c and
    xf86int10.c alongside stub.c; autotools built only stub.c and
    xf86int10module.c. Linking fails because stub.c and helper_exec.c
    both define xf86InitInt10(), and on non-x86 Linux the helpers fail
    to compile first, since int10Defines.h includes <asm/vm86.h> when
    _VM86_LINUX is defined. Drop that define for stub too; nothing in
    the stub build uses it any more.
    
    This went unnoticed until 71c7824e8 ("meson: check cpu_family()
    instead of cpu()") made int10=auto pick stub on 32-bit arm. Native
    arm builds report cpu() as armv7l or similar, so the old check
    never matched.
    
    Fixes: 1549e3037 ("Add a Meson build system alongside autotools.")
    Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1929
    Signed-off-by: Matt Turner <mattst88@gmail.com>
    (cherry picked from commit eae2c2107746648d0919204d82015c38a83ae313)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2375>

commit a10192e7c3237a707e9bb712a566e2f14415dddd
Author: Alan Coopersmith <alan.coopersmith@oracle.com>
Date:   Sat Oct 10 12:53:56 2026 -0700

    Revert "damage: Unlink a damage from the list it was actually inserted on"
    
    This reverts commit 0fb16f3da03c077f5821f0eeb745384f5472faa5.
    
    I missed that it broke driver ABI when I cherry-picked it from main to the
    server-21.1-branch.   Apologies.
    
    Closes: #1930
    Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2355>

commit edc1b378f804ef5bf286318057e0b935f91f22b7
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Wed Oct 7 11:19:46 2026 +1000

    xserver 21.1.25
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2346>

commit 4c9c345d2a10baf956fdefa83bb88681f7c840cf
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Thu Sep 3 14:57:31 2026 +1000

    Xi: clean up gesture sprite traces in WindowGone
    
    Gesture sprite traces which have the same 'fixed sprite trace
    for the duration of the gesture' logic as touch sprite traces.
    Both copy WindowPtrs into the trace without refcounting them.
    
    If a device supports gestures but does not have a TouchClass,
    the cleanup skipped over the gesture sprite cleanup, leaving
    dangling pointers in place if a sprite trace is destroyed
    during an active gesture (i.e. window is removed).
    
    DeliverOneGestureEvent() then dereferences the stale pointer via
    DeepestSpriteWin(&gi->sprite)->drawable.id, causing a use-after-free.
    
    This vulnerability was discovered by:
      4nibhal working with TrendAI Zero Day Initiative
    
    ZDI-CAN-32753
    
    CVE-2026-93536
    
    Assisted-by: Claude:claude-opus-4-6
    (cherry picked from commit efcfd8acc754c5ac4b2555ff375dd5101d735b0a)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2343>

commit 9c3880d0745acefc98ed37e79498dfbe558a0f40
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Wed Aug 26 17:17:12 2026 +1000

    Xi: add bounds check for barrier events in input_constrain_cursor
    
    input_constrain_cursor() writes barrier hit and leave events into the
    InputEventList buffer without checking how many slots remain.
    The buffer is allocated by the DDX at GetMaximumEventsNum() (100) entries
    and may contain one raw event already. A client can create more than 100
    pointer barriers, pre-arm them as released via XIBarrierReleasePointer,
    and then trigger a single pointer motion that crosses all barriers
    simultaneously. The leave event loop iterates every hit barrier and
    writes one event per barrier, overflowing the 100-slot buffer.
    
    In an ideal world we'd change the InternalEvent* pointer to a struct
    that contains allocated size, number of events and the pointer itself
    but we're crossing public APIs here and that requires an ABI bump.
    
    So we make do with cutting off the number of barrier events at 64 which
    should be low enough to not trigger the issue. However, for the 100+
    barrier case this means we only send BarierHit events, not BarrierRelease.
    Potentially leaving a client stuck.
    
    We mitigate that problem by simply refusing to create more than 32
    barriers per screen (which on its own would also fix the issue, but hey,
    'doppelt gemoppelt' as they say).
    
    This vulnerability was discovered by:
      Anonymous working with TrendAI Zero Day Initiative
    
    ZDI-CAN-31938
    
    CVE-2026-93519
    
    Assisted-by: Claude:claude-opus-4-6
    (cherry picked from commit 1f42cc1f00d9c6d46978ae82dba8a52f4d902369)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2343>

commit 9442a53c137bb9eb61336c6fd39627912d50cc8d
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Tue Oct 6 15:48:30 2026 +1000

    dix: remove passive grabs referencing a device on removal
    
    Passive grabs (GrabRec) store raw DeviceIntPtr values for both the
    grabbed device and the modifier device without any lifetime management.
    When a device is removed via XIRemoveMaster, CloseDevice() frees the
    device struct, but leaves dangling pointers in grab->modifierDevice
    for any grab that used this device.
    
    Subsequent pointer events trigger CheckPassiveGrab() which dereferences
    the dangling modifierDevice pointer for XI grabs (the CORE and XI2 paths
    reassign it, but the XI path does not).
    
    This vulnerability was discovered by:
      Anonymous working with TrendAI Zero Day Initiative
    
    ZDI-CAN-31832
    
    CVE-2026-93516
    
    Assisted-by: Claude:claude-opus-4-6
    (cherry picked from commit be572634158850fff4e9829cee88db08d30c9743)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2343>

commit a469f98bcfab50dab607ff5ac24037632b0079a3
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Wed Aug 26 17:04:47 2026 +1000

    present: unlink notifies from window list in present_clear_window_notifies
    
    When a window is destroyed, present_clear_window_notifies()
    does not remove the notify list node from the window. The notify
    may then be freed as part of the window_priv, leaving dangling
    pointers in place.
    
    When the vblank owning the notify is later torn down,
    present_free_window_notify() calls xorg_list_del() which
    writes through these dangling pointers (use-after-free write).
    
    This happens when Present cross-window notifies are used: a
    PresentPixmap on window A can reference window B as a notify target.
    An untriggered wait_fence keeps the vblank alive so that B can be
    destroyed first, creating the dangling-pointer window.
    
    Fix this by calling the free function we have (and moving the window
    reset into that function too). present_clear_window_notifies is only
    called from one place anyway.
    
    This vulnerability was discovered by:
      Anonymous working with TrendAI Zero Day Initiative
    
    ZDI-CAN-31830
    
    CVE-2026-93515
    
    Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
    Assisted-by: Claude:claude-opus-4-6
    (cherry picked from commit 1b6955c3108e6b43433aefe860070708e6f43d1b)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2343>

commit 3961cdca467975a7d377f1f7bcd55d52eb3f417a
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Wed Aug 26 17:16:49 2026 +1000

    glx: validate dataBytes against cmdlen in RenderLarge first request
    
    __glXDisp_RenderLarge() allocates the large command buffer based on
    cmdlen (from hdr->length, the total command size embedded in the
    payload), but copies dataBytes (from req->dataBytes, the payload size
    of the current sub-request) into it. The existing length check only
    validates that the X11 request length is consistent with dataBytes,
    not that dataBytes fits within the cmdlen-sized buffer.
    
    A malicious client can set hdr->length to a small value (e.g. 12 bytes)
    while sending a large dataBytes (up to ~256KB or more with
    BIG-REQUESTS), causing the memcpy to overflow the cmdlen-sized buffer.
    
    Add a check that dataBytes <= cmdlen before the buffer allocation and
    copy on the first request.
    
    This vulnerability was discovered by:
      Anonymous working with TrendAI Zero Day Initiative
    
    ZDI-CAN-31833
    
    CVE-2026-93517
    
    Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
    Assisted-by: Claude:claude-opus-4-6
    (cherry picked from commit 2abe4632d793314d3d5f28c19583fb76019f5ce4)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2343>

commit aa56160fa213d8767e7da0c076b5c8242703313b
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Wed Aug 26 17:04:20 2026 +1000

    Xi: validate modifier values in ProcXIPassiveUngrabDevice
    
    ProcXIPassiveUngrabDevice() passes client-supplied modifier values
    directly to DeletePassiveGrabFromList() without validating them.
    
    DeletePassiveGrabFromList() may reach DeleteDetailFromMask() which uses
    BITCLEAR(mask, modifier). The mask is allocated as 8 Mask words (256
    bits). A modifier value > 255 causes BITCLEAR to index mask[modifier>>5]
    past the allocation, resulting in a controlled single-bit-clear at an
    attacker-chosen heap offset.
    
    Add the same modifier validation that CheckGrabValues() uses: reject
    modifiers that are not XIAnyModifier and have bits set outside
    AllModifiersMask.
    
    This vulnerability was discovered by:
      Anonymous working with TrendAI Zero Day Initiative
    
    ZDI-CAN-32366
    
    CVE-2026-93523
    
    Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
    Assisted-by: Claude:claude-opus-4-6
    (cherry picked from commit 37a1847a60c6799aecf163a5cfa40077a9002675)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2343>

commit 00ce692c7f6ea1900888a2a24aecf6cba5544ae1
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Wed Aug 26 17:04:35 2026 +1000

    randr: fix size and offset in RRChangeProviderProperty PrependMode
    
    RRChangeProviderProperty() has two bugs in the PropModePrepend case:
    
    1. new_value.size is set to 'len' (the new data length) instead of
       'total_len' (len + prop_value->size), losing track of the existing
       data. This also affects PropModeAppend.
    
    2. The old_data offset is computed using prop_value->size instead of
       len. For PrependMode, the layout should be [new(len)][old(size)],
       so old_data should start at len * size_in_bytes.
    
    These bugs are analogous to the ones fixed in RRChangeOutputProperty(),
    see commit 541ab2ecd41d ("Xi/randr: fix handling of PropModeAppend/Prepend").
    
    This vulnerability was discovered by:
      Anonymous working with TrendAI Zero Day Initiative
    
    ZDI-CAN-31944
    
    CVE-2026-93521
    
    Assisted-by: Claude:claude-opus-4-6
    Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
    (cherry picked from commit 5dc9efd5a199717b53f70b9c6cd336a522370e46)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2343>

commit 927ee1282d21550807619521bee909ef62ed0571
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Thu Sep 3 14:55:27 2026 +1000

    xkb: fix CheckKeySyms overwriting request-range symsPerKey entries
    
    CheckKeySyms() has two loops: the first processes keys in the SetMap
    request range, the second fills in any missing keys from the existing
    map.
    
    The indexing between the two was inconsistent: the first loop
    uses a zero-based index + req->firstKeySym, the second loop used it just
    as zero-based index.
    
    Example:
       req->firstKeySym = 50
       req->nKeySyms = 10
    
      i goes from 0 to 10,
      loop 1 checks [50, 60), changes the width but finishes with i at 10.
      loop 2 then runs over [10, 255(, copying the old keymap width
    
    The second loop overwrites the new widths with the width of the
    existing keymap. The subsequent SetKeySyms worked on the new width
    and may write fewer actions than the map width.
    
    A subsequent XkbGetMap request would then read XkbKeyNumActions()
    entries (derived from the new wider key_sym_map.width) from the shorter
    action allocation, causing an out-of-bounds heap read. The overread
    bytes would be copied into the GetMap reply and sent back to the client,
    producing a bounded heap information disclosure.
    
    This vulnerability was discovered by:
      WONJOON HWANG (@joon1337) working with TrendAI Zero Day Initiative
    
    ZDI-CAN-32408
    
    CVE-2026-93524
    
    Assisted-by: Claude:claude-opus-4-6
    (cherry picked from commit cea71d0273e4d5092aa9c6a8a770734c8935c02e)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2343>

commit 558ba8f784b0f5d4d96948051b2f04c983af20cc
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Wed Aug 26 16:57:38 2026 +1000

    xkb: widen size_syms, num_syms, size_acts, num_acts to unsigned int
    
    Fields in XkbClientMapRec and XkbServerMapRec that denote size/num
    and are unsigned short can result in truncations. For example
    when XkbResizeKeyType() computes the new size_syms value as
    (nTotal * 15) / 10, the result may be implicitly truncated to 16
    bits on assignment. This causes an undersized calloc allocation, and the
    subsequent copy loop writes based on the actual (untruncated) key count,
    resulting in a heap buffer overflow. A similar truncation may happen
    in XkbResizeKeySyms() and XkbResizeKeyActions().
    
    Widen the fields from unsigned short to unsigned int. These are internal
    server structures, not wire protocol types.
    
    This vulnerability was discovered by:
      Anonymous working with TrendAI Zero Day Initiative
    
    ZDI-CAN-31834
    
    CVE-2026-93518
    
    Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
    Assisted-by: Claude:claude-opus-4-6
    (cherry picked from commit 89101a6c6618f543d7502f2077c7ef1a507af256)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2343>

commit 5ec0535af2bcc93381666dc110abebba8975f8ae
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Wed Aug 26 17:04:03 2026 +1000

    xkb: allocate names->keys to MAP_LENGTH in XkbAllocNames
    
    Commit a3171732d ("xkb: Always use MAP_LENGTH keymap size") converted
    most XKB allocation functions to use MAP_LENGTH (256) instead of
    max_key_code + 1. It also removed the per-array reallocarray() calls in
    XkbChangeKeycodeRange(), replacing them with a memset up to MAP_LENGTH.
    However, XkbAllocNames() was missed and still allocates names->keys to
    max_key_code + 1.
    
    When a keycodes component with max_key_code < 255 is loaded (e.g.
    sun(type6) with max_key_code=132) and then a SetMap request extends
    maxKeyCode to 255, XkbChangeKeycodeRange() memsets names->keys from
    max_key_code to MAP_LENGTH-1, writing past the undersized allocation.
    
    Fix by allocating names->keys to MAP_LENGTH, consistent with all other
    keymap arrays after a3171732d.
    
    This vulnerability was discovered by:
      Anonymous working with TrendAI Zero Day Initiative
    
    ZDI-CAN-31941
    
    CVE-2026-93520
    
    Fixes: a3171732da50 ("xkb: Always use MAP_LENGTH keymap size")
    
    Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
    Assisted-by: Claude:claude-opus-4-6
    (cherry picked from commit b941a473e06f26a407a9adb15759be79f7418e86)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2343>

commit c724006ee76fb002add50fcb4d97e8c96c279f09
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Wed Aug 26 16:53:56 2026 +1000

    xkb: NULL text pointer after free in _CheckSetDoodad error path
    
    _CheckSetDoodad() allocates doodad->text.text via _GetCountedString()
    and then attempts to allocate doodad->text.font. If the font string
    allocation fails (e.g. because the font string length extends past
    the request boundary), the error handler frees doodad->text.text but
    does not NULL the pointer. The doodad was already added to the geometry
    by XkbAddGeomDoodad() before the string allocations, so when
    XkbFreeGeometry() runs cleanup, _XkbClearDoodad() frees the same
    dangling pointer again, resulting in a double-free.
    
    NULL the pointer after freeing it to prevent the double-free.
    
    This vulnerability was discovered by:
      Anonymous working with TrendAI Zero Day Initiative
    
    ZDI-CAN-31221
    
    CVE-2026-88812
    
    Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
    Assisted-by: Claude:claude-opus-4-6
    (cherry picked from commit 0d1b1b0bad86c9ea2a3b7ca5a70e681dc69f1ecc)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2343>

commit cd6e05243d640806266a75467788d71ca3b0f4f2
Author: stefan11111 <stefan11111github@gmail.com>
Date:   Tue Aug 25 23:50:53 2026 +0300

    glamor: Set `need_free_region` immediately after pixman region allocation
    
    Otherwise, the region would leak when the pixmap is not in gpu memory
    
    Signed-off-by: stefan11111 <stefan11111github@gmail.com>
    (cherry picked from commit 41b3d993baf5cbcff7045e63ad0d3d8aebf1dc67)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2336>

commit 1eb172748e3e115b7a94e603129a6a79dd65356f
Author: Alan Coopersmith <alan.coopersmith@oracle.com>
Date:   Sun Sep 13 15:16:44 2026 -0700

    xf86: mark wasset unused in xf86UnblockSIGIO() compatibility wrapper
    
    Avoids a gcc warning in every file that includes it,
    whether in the server or drivers:
    
    /usr/include/xorg/xf86.h: In function ‘xf86UnblockSIGIO’:
    /usr/include/xorg/xf86.h:86:55: warning: unused parameter ‘wasset’ [-Wunused-parameter]
       86 | static inline _X_DEPRECATED void xf86UnblockSIGIO(int wasset) { input_unlock(); }
          |                                                   ~~~~^~~~~~
    
    Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
    (cherry picked from commit 306071c0b9683ef0dfadcfc2dbb78d369680542b)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2336>

commit be8da1869b1082a35a305cd6602016f2a5d936e1
Author: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Date:   Mon Aug 17 01:15:52 2026 -0700

    xkb: Keep the group counts of a loaded keymap in range
    
    Clamp the count once per key and use it everywhere the key or the keymap is indexed with it, while still reading
    every symbol the file claimed so that the stream stays in step and the symbol array is not left short.
    
    At the other end, a symbols section in which no key defines any group leaves the count at the zero it was
    allocated with.  This is how XQuartz's keyboard is initialized: model "empty" supplies a symbols section that
    defines no keys, and a section that defines nothing is still a section, so XkbInitControls() sees XkmSymbolsMask
    and skips its own single-group default.  The device only survives because DarwinKeyboardReloadHandler()
    immediately pushes a core keymap that raises the count again.
    
    Fixes: https://github.com/XQuartz/XQuartz/issues/422
    Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
    (cherry picked from commit 0c764d98eef507df8e32ac1a84df6782999b5994)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2336>

commit e43063a239c65da9a6208e02dd19c0a899b99600
Author: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Date:   Mon Aug 17 00:35:52 2026 -0700

    xkb: Never recompute a keymap's group count down to zero
    
    Both places that derive ctrls->num_groups from the widest key in the map can arrive at zero.  But a keymap in
    which no key defines any symbols is legal, so ensure we declare at least one group.
    
    Fixes: https://github.com/XQuartz/XQuartz/issues/422
    Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
    (cherry picked from commit aa0bc93d27813a33f3484c861a87c26441b5ea2a)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2336>

commit c1f87673a43f299f4f5a06663ce7fa43133a4732
Author: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Date:   Mon Aug 17 01:15:52 2026 -0700

    xkb: Default to one group whenever a keymap reports none
    
    XkbInitControls() had a fallback to ensure keymaps that defined no symbols at all still resulted in one group.
    Extend this to cover the case where a keymap reports symbols but no groups.
    
    Fixes: https://github.com/XQuartz/XQuartz/issues/422
    Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
    (cherry picked from commit 8e11715024a5167c9554be7b49c4d6ca0bd2c73b)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2336>

commit 0cfe0657853161185843bb2e338f4da259cc8701
Author: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Date:   Sun Aug 16 23:57:26 2026 -0700

    xkb: Guard XkbAdjustGroup() against a keymap with no groups
    
    When every key in a keymap has zero groups, ctrls->num_groups is 0 and each out-of-range action here misbehaves.
    XkbWrapIntoRange divides by zero, which is the reported crash.  XkbClampIntoRange is worse: it computes -1,
    returns it through this function's unsigned type, and the callers truncate it into XkbStateRec's unsigned char
    group fields as 255, after which XkbComputeCompatState() reads map->groups[255] out of a four element array and
    reports what it finds to clients in the compat state of every core event.  The negative-group case adds zero
    forever, wedging the server thread, in one path while it holds input_lock.  XkbComputeDerivedState() treats group
    0 as out of range once num_groups is 0, so all of this is reachable from an ordinary key event.
    
    XQuartz gets there because it asks for model "empty", whose keycodes file declares no key names, so a keymap
    compiled at a client's request has no key definitions at all.
    
    Guard the arithmetic itself and not just the places that compute num_groups: groups_wrap selects between these
    actions and is client settable, and this is exported for DDXes that supply their own controls.
    
    Fixes: https://github.com/XQuartz/XQuartz/issues/422
    Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
    (cherry picked from commit bdb14dce4b62c37abb3ea9e5edba2eca46b2dbab)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2336>

commit 0fb16f3da03c077f5821f0eeb745384f5472faa5
Author: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Date:   Sun Aug 16 21:21:11 2026 -0700

    damage: Unlink a damage from the list it was actually inserted on
    
    DamageRegister() chooses which list a damage is linked onto via getDrawableDamageRef(), but DamageUnregister() and
    damageSetWindowPixmap() re-derived that list at removal time.  For a window the answer depends on the window pixmap,
    which changes while the damage is registered (Composite redirection, rootless drawing and Present flips all swap it), so
    the removal could consult a different list than the one the damage was inserted onto.  It then silently found nothing --
    DAMAGE_VALIDATE_ENABLE is off, so the diagnostic is compiled out -- and left an unregistered, often freed, damage linked
    where damageRegionAppend() would later dereference its NULL pDrawable and crash.
    
    Record the list head when linking a damage and always unlink from that, which also drops a use-after-free read of the
    old window pixmap in damageSetWindowPixmap(): rootless frees its scratch pixmap before restoring the pre-drawing window
    pixmaps, so the pixmap consulted there had already been destroyed.
    
    Fixes: https://github.com/XQuartz/XQuartz/issues/406
    
    Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
    (cherry picked from commit da72833185481481052972f031262e94976131ef)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2336>

commit 5981d49e9a26d5401d80f3ef591033cc5faa7e05
Author: Alan Coopersmith <alan.coopersmith@oracle.com>
Date:   Thu Aug 27 09:59:44 2026 -0700

    meson: check cpu_family() instead of cpu()
    
    meson documents the values returned by cpu_family() as stable,
    but not those returned by cpu():
    https://mesonbuild.com/Reference-tables.html#cpu-families
    https://mesonbuild.com/Reference-manual_builtin_host_machine.html
    
    We already use cpu_family() in most instances, but had missed a few.
    
    Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
    (cherry picked from commit 71c7824e806b1f216a2a90e12d3d3b7de9d1a7a9)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2336>

commit 1bef8d9fd89a456207049b9999e7e65696bcced7
Author: pkubaj <pkubaj@anongoth.pl>
Date:   Fri Aug 5 12:02:50 2022 +0000

    meson: Fix build on FreeBSD/powerpc*
    
    Current error:
    ld: error: undefined symbol: xf86EnableIO
    >>> referenced by xf86Configure.c
    >>>               libxorg_common.a.p/xf86Configure.c.o:(DoConfigure) in archive hw/xfree86/common/libxorg_common.a
    >>> referenced by xf86Events.c
    >>>               libxorg_common.a.p/xf86Events.c.o:(xf86VTEnter) in archive hw/xfree86/common/libxorg_common.a
    >>> referenced by xf86Init.c
    >>>               libxorg_common.a.p/xf86Init.c.o:(InitOutput) in archive hw/xfree86/common/libxorg_common.a
    >>> referenced 1 more times
    
    (cherry picked from commit 8c54d590cbcad5579548d53499ce0bf501bd56bb)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2336>

commit d3d92167d195724dd4b3bfd56852ba74eb17790d
Author: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Date:   Thu Aug 20 00:11:23 2026 -0700

    RegionValidate: Fix double free of badreg->data on the error path
    
    RegionValidate() copies *badreg into ri[0].reg, so ri[0].reg.data aliases badreg->data. A later
    RECTALLOC_BAIL() can realloc() that block and move it, updating ri[0].reg.data but not badreg->data. On
    the bail path, freeing ri[0].reg.data and then calling RegionBreak(badreg) frees badreg->data a second
    time, which by then is a stale pointer into memory already freed or reallocated to something else.
    
    Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
    (cherry picked from commit 4ef1b4cd2690c6d8e4b029b02bf707cb04d0da24)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2336>

commit 5ca3b07fa21bf8af9ef95db9cc768804047243e8
Author: Lukáš Lipinský <18076-Mr-Tao@users.noreply.gitlab.freedesktop.org>
Date:   Wed Aug 26 01:08:28 2026 +0200

    Xi: byte-swap XIQueryDevice ScrollClass flags
    
    SwapScrollInfo converted the other multi-byte ScrollClass fields but left flags in server byte order. Swap it as well and decode the field in the swapped-client protocol test so nonzero flags exercise the wire representation.
    
    Signed-off-by: Lukáš Lipinský <18076-Mr-Tao@users.noreply.gitlab.freedesktop.org>
    (cherry picked from commit 8033c4d93ea140025fea5e7294bb4e92c0cd6af5)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2336>

commit 608f870d9c82fed25bab0c94a6563bbbb09f1002
Author: Lukáš Lipinský <18076-Mr-Tao@users.noreply.gitlab.freedesktop.org>
Date:   Wed Aug 26 01:07:50 2026 +0200

    Xi: byte-swap DeviceChanged valuator and scroll data
    
    SDeviceChangedEvent left ValuatorClass.value and every ScrollClass-specific multi-byte field in server byte order. Swapped clients therefore received corrupt current values and scroll metadata.
    
    Swap those fields and extend the protocol event conversion coverage to nonzero relative valuator values and both scroll directions and flags.
    
    Signed-off-by: Lukáš Lipinský <18076-Mr-Tao@users.noreply.gitlab.freedesktop.org>
    (cherry picked from commit cf91b97d6c7c3ec24a4b161484921f5d4ca5a6de)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2336>

commit 9b6673ece4a791fff30b263da649d6e230358c3b
Author: Alan Coopersmith <alan.coopersmith@oracle.com>
Date:   Sun Aug 30 17:48:34 2026 -0700

    meson: only install dri3.h if building dri3 support
    
    Reported-by: Thomas Klausner <wiz@gatalith.at>
    Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
    (cherry picked from commit dc8e08825aba7e387e81773647b2257f2189c6f8)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2336>

commit abe6547728ad3b4ce5d6b60071d327540962e441
Author: Alan Coopersmith <alan.coopersmith@oracle.com>
Date:   Sun Aug 9 14:03:19 2026 -0700

    Handle -Wimplicit-fallthrough warnings from gcc 16.1
    
    Gets rid of 36 -Wimplicit-fallthrough warnings
    
    Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
    (cherry picked from commit 989e42c1d46a241bd54475d2e062dceed314a97a)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2336>

commit 4a55d1ddb5cf7f2ae49acf608661e960e83e2814
Author: Alan Coopersmith <alan.coopersmith@oracle.com>
Date:   Sun Aug 9 11:28:39 2026 -0700

    xf86: handle malloc failure in DoSubstitution()
    
    Reported by gcc 16.1:
    
    hw/xfree86/parser/scan.c:562:65: warning: use of possibly-NULL ‘result’
     where non-null expected [CWE-690] [-Wanalyzer-possible-null-argument]
      562 |                         strcpy(result + l, s);                  \
          |                         ^~~~~~~~~~~~~~~~~~~~
    hw/xfree86/parser/scan.c:595:21: note: in expansion of macro ‘APPEND_STR’
      595 |                     APPEND_STR(cmdline);
          |                     ^~~~~~~~~~
    
    Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
    (cherry picked from commit c26e2081cba3fdf79bd6fe6e37f042d26b2a930e)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2336>

commit 04a8af363f451a5a054f3df211f0a64bd9b4cf04
Author: Alan Coopersmith <alan.coopersmith@oracle.com>
Date:   Sun Aug 9 11:10:42 2026 -0700

    exa: silence -Wold-style-declaration warning from gcc 16
    
    exa/exa_accel.c:239:1: warning: ‘inline’ is not at beginning of declaration
     [-Wold-style-declaration]
      239 | static Bool inline
          | ^~~~~~
    
    Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
    (cherry picked from commit 3d22aaf07f4d6397885a44f33bca69a0c5c47337)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2336>

commit 9f933f5e660f100a7a090c660dd90f76a4548ba1
Author: Alan Coopersmith <alan.coopersmith@oracle.com>
Date:   Sun Aug 9 10:46:43 2026 -0700

    test: silence -Wanalyzer-null-argument warnings in strndup tests
    
    Catch malloc failures before calling strcmp() with them.
    
    Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
    (cherry picked from commit e7644f938afa7e9748345e65fb2d7be745c59635)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2336>

commit 9ac6dd95044871ca940c7692bcfc6dfcb840e80f
Author: Alan Coopersmith <alan.coopersmith@oracle.com>
Date:   Sun Aug 9 10:40:45 2026 -0700

    xf86: silence -Wanalyzer-possible-null-dereference warning in parser
    
    Reported by gcc 16.1:
    hw/xfree86/parser/Files.c:131:41: warning: dereference of possibly-NULL
[--snip--]
