commit 8570e9fcec845f68f0c90caa51fd7a24764ea220
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Tue Jun 2 10:02:58 2026 +1000

    xserver 21.1.23
    
    Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2231>

commit f0b8e6e1d969548c0625051d56a780e5df39de26
Author: Michel Dänzer <mdaenzer@redhat.com>
Date:   Fri May 15 17:47:51 2026 +0200

    dri2: Deduplicate attachments in do_get_buffer
    
    It was always the intention of the DRI2 protocol that there's at most
    one instance of each attachment, and that's how it was implemented in
    Mesa.
    
    Since that wasn't enforced though, there might be other clients in the
    wild which (e.g. accidentally) request the same attachment multiple
    times. So starting to a raise a protocol error in this case now risks
    breaking such clients.
    
    Instead, just deduplicate the attachments using a bit-set.
    
    This has a couple of desirable side effects:
    
    * destroy_buffer cannot be called multiple times for the same
      DRI2BufferPtr.
    * The client cannot cause the server to allocate a buffers array with
      more entries than there are attachments (currently 11).
    
    Signed-off-by: Michel Dänzer <mdaenzer@redhat.com>
    (cherry picked from commit 339c279514326134b0878fc23ce6e9520440ce7f)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2229>

commit 4926348d826b7dc12d51d7e41bd9068aee5f90af
Author: Michel Dänzer <mdaenzer@redhat.com>
Date:   Wed May 13 14:29:26 2026 +0200

    dri2: Use booleans for (fake) front buffer tracking in do_get_buffers
    
    This works as intended — the (fake) front buffer needs to be added
    only if the client didn't request it in the first place — even if the
    client requests the same attachment multiple times. This ensures we
    never try to access more than (count + 1) entries of the buffers array.
    
    Fixes: ff6c7764c290 ("DRI2: Implement protocol for DRI2GetBuffersWithFormat")
    Signed-off-by: Michel Dänzer <mdaenzer@redhat.com>
    (cherry picked from commit b7aa65cc3bb11b792ce2a3f511ba9b863acb11c8)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2229>

commit a569eb4f36ed96a9e445ececd7e8d98c223461a0
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Wed Apr 29 05:40:33 2026 +0000

    dix: increase XLFDMAXFONTNAMELEN to match libXfont2's MAXFONTNAMELEN
    
    XLFDMAXFONTNAMELEN was 256 bytes, but libXfont2 defines MAXFONTNAMELEN
    as 1024 and allows font names and alias targets up to that length in
    fonts.alias files.
    
    doListFontsAndAliases copies the resolved alias target into a
    stack-allocated tmp_pattern[XLFDMAXFONTNAMELEN] and then into
    c->current.pattern[XLFDMAXFONTNAMELEN] (defined in LFWIstateRec).
    doListFontsWithInfo has the same pattern, copying the resolved name into
    c->current.pattern[]. With the old 256-byte limit, a fonts.alias entry
    with a target name between 257 and 1023 bytes would overflow both
    buffers.
    
    An attacker can exploit this by:
      1. Creating a font directory with a fonts.alias containing an alias
         whose target name exceeds 256 bytes
      2. Using SetFontPath to add the malicious directory
      3. Calling ListFonts with the alias name to trigger alias resolution
      4. The oversized resolved name overflows the 256-byte stack buffer
    
    Increase XLFDMAXFONTNAMELEN from 256 to 1024 to match libXfont2's
    MAXFONTNAMELEN, ensuring the server can handle any name the font library
    produces.
    
    This vulnerability was discovered by:
    Anonymous working with TrendAI Zero Day Initiative
    
    ZDI-CAN-30136
    
    Assisted-by: Claude:claude-opus-4-6
    (cherry picked from commit bb5158f962dc935e58ef8b4b5fcb31be201a6e07)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2229>

commit 182c23f780402062ab31963776a19d5b87e25ac8
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Mon Apr 20 11:19:20 2026 +1000

    saver: re-fetch screen private after CheckScreenPrivate in CreateSaverWindow
    
    CreateSaverWindow stores pPriv (the ScreenSaverScreenPrivatePtr) in a local
    variable via the SetupScreen macro at function entry. When an existing saver
    window is being replaced, the function sets pPriv->hasWindow = FALSE and
    calls CheckScreenPrivate(). If at this point pPriv->attr is NULL (cleared
    by a prior UnsetAttributes call), pPriv->events is NULL, and
    pPriv->installedMap is None, then CheckScreenPrivate determines the screen
    private is unused, frees it, and sets the screen private pointer to NULL.
    
    The function then continues to dereference the now-freed pPriv on the very
    next line (pPriv->attr), resulting in a use-after-free. On glibc 2.34+,
    the tcache key at offset 8 within the freed block makes pPriv->attr appear
    non-NULL, causing the function to continue operating on garbage data and
    eventually crash.
    
    The attack sequence is:
      1. SetAttributes (creates pPriv with pPriv->attr set)
      2. ForceScreenSaver(Active) (creates saver window, pPriv->hasWindow=TRUE)
      3. UnsetAttributes (sets pPriv->attr = NULL)
      4. ForceScreenSaver(Active) (re-enters CreateSaverWindow → UAF)
    
    Fix by re-fetching pPriv from the screen private after CheckScreenPrivate
    returns, so the subsequent NULL check correctly detects the freed state.
    
    ScreenSaverFreeAttr has the same pattern, force pPriv to NULL there too
    even though it has no real effect.
    
    This vulnerability was discovered by:
    Anonymous working with TrendAI Zero Day Initiative
    
    ZDI-CAN-30168
    
    Assisted-by: Claude:claude-opus-4-6
    (cherry picked from commit ecc634f1b2f7aa473d3a267eada98c4918bf9e05)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2229>

commit 94341bd715d62ba8da4c1851f517018996da1af8
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Mon Apr 20 11:18:48 2026 +1000

    glx: fix reversed length check in ChangeDrawableAttributes
    
    The request length validation in __glXDisp_ChangeDrawableAttributes and
    __glXDispSwap_ChangeDrawableAttributes uses the wrong comparison direction.
    The check tests whether the computed request size is LESS THAN
    client->req_len, but should test whether it is GREATER THAN. With the
    reversed operator, an undersized request (where numAttribs claims more
    attribute pairs than the request actually contains) passes validation.
    
    DoChangeDrawableAttributes then iterates numAttribs attribute pairs starting
    from the end of the request header, reading past the actual request data
    into adjacent memory. This is an out-of-bounds read that can also cause
    an out-of-bounds write when a GLX_EVENT_MASK attribute key is found in the
    overread data and its corresponding value is written to pGlxDraw->eventMask.
    
    This patch effectively reverts commit 402b329c3aa8 ("glx: Work around
    wrong request lengths sent by mesa"). This was fixed in mesa commit
    4324d6fdfbba1 in 2011 (mesa 7.11).
    
    Fixes: 402b329c3aa8 ("glx: Work around wrong request lengths sent by mesa")
    
    This vulnerability was discovered by:
    Anonymous working with TrendAI Zero Day Initiative
    
    ZDI-CAN-30165
    
    Assisted-by: Claude:claude-opus-4-6
    (cherry picked from commit 6d459e4daf715bea8abdafa8fb130be2f8a1d145)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2229>

commit 54c3d9fad0f2f97835da9d275b53255f4963029f
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Mon Apr 20 11:18:13 2026 +1000

    xkb: clamp nMaps to mapWidths buffer size in CheckKeyTypes
    
    CheckKeyTypes computes nMaps = firstType + nTypes from client-controlled
    request fields when XkbSetMapResizeTypes is set. This value is used to
    index mapWidths[], a stack-allocated CARD8 array of XkbMaxLegalKeyCode + 1
    (256) elements. No upper bound is enforced on nMaps.
    
    An attacker can first send SetMap(firstType=0, nTypes=255, ResizeTypes) to
    set the server's num_types to 255, then send SetMap(firstType=255,
    nTypes=10, ResizeTypes). The firstType > num_types check passes because
    255 > 255 is false (the check uses > rather than >=). nMaps is then
    computed as 265, and the loop writes mapWidths[255..264], overflowing 9
    bytes past the stack buffer into adjacent stack variables (symsPerKey[]).
    
    Fix by rejecting requests where firstType + nTypes would exceed the
    mapWidths buffer size (XkbMaxLegalKeyCode + 1).
    
    This vulnerability was discovered by:
    Anonymous working with TrendAI Zero Day Initiative
    
    ZDI-CAN-30161
    
    Assisted-by: Claude:claude-opus-4-6
    (cherry picked from commit 867b59b33bee669cb412f1314e47c52eacf6e00b)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2229>

commit eced7e74cad4a46c3a3c17b2df13b70b8bedfc25
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Mon Apr 20 11:17:41 2026 +1000

    xkb: reject key types with num_levels exceeding XkbMaxShiftLevel
    
    CheckKeyTypes validates incoming key type definitions from XkbSetMap
    requests but does not enforce an upper bound on numLevels. A client can set
    numLevels up to 255 on a non-canonical key type, which is stored in the
    server's type table.
    
    When ChangeKeyboardMapping later triggers XkbUpdateKeyTypesFromCore, the
    function XkbKeyTypesForCoreSymbols computes groupsWidth from num_levels and
    uses the XKB_OFFSET(g, l) = (g * groupsWidth) + l macro to index into
    tsyms[], a stack-allocated buffer of XkbMaxSymsPerKey (252) entries. With
    num_levels=255, groupsWidth=255, and indices reach up to 3*255+254 = 1019,
    overflowing the 252-element stack buffer by 767 KeySym-sized entries.
    
    Fix by rejecting numLevels values greater than XkbMaxShiftLevel (63) in
    CheckKeyTypes, alongside the existing lower-bound check for numLevels < 1.
    
    This vulnerability was discovered by:
    Anonymous working with TrendAI Zero Day Initiative
    
    ZDI-CAN-30160
    
    Assisted-by: Claude:claude-opus-4-6
    (cherry picked from commit 543e108516428fc8c3bea91d6563ad266f9a801e)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2229>

commit 92a167ab3fda0bee41cf97f6a40a4c01c67d85d4
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Mon Apr 20 11:17:08 2026 +1000

    sync: restart trigger list iteration in SyncChangeCounter after TriggerFired
    
    This is the equivalent check to miSyncTriggerFence() from
    commit f19ab94ba9c8 ("miext/sync: Fix use-after-free in miSyncTriggerFence()")
    
    When a trigger fires via SyncAwaitTriggerFired, the resulting
    FreeResource/FreeAwait call invokes SyncDeleteTriggerFromSyncObject for
    every trigger in the same Await group. This unlinks and frees the
    corresponding trigger list nodes - potentially including the node pnext
    points to.
    
    Fix by restarting iteration from the list head after a trigger fires, since
    TriggerFired may have arbitrarily mutated the list. Triggers that have fired
    are removed from the list by FreeAwait, so restarting cannot cause infinite
    loops.
    
    This vulnerability was discovered by:
    Anonymous working with TrendAI Zero Day Initiative
    
    ZDI-CAN-30164
    
    Assisted-by: Claude:claude-opus-4-6
    (cherry picked from commit bdd7bf57af208b1ddf57d4683d67104443b44812)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2229>

commit f304b57444be3991fd9d3389f309c6eeb056a6c4
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Mon Apr 20 11:16:13 2026 +1000

    sync: fix deletion of counters and fences
    
    Both FreeCounter() and miSyncDestroyFence() iterate over the trigger list
    and invoke the CounterDestroyed callback on each trigger.
    
    The CounterDestroyed callback (e.g. SyncAwaitTriggerFired) may call
    FreeResource/FreeAwait, which frees the SyncAwaitUnion containing all
    SyncAwait structs in the same Await group.
    
    When multiple conditions in a single Await reference the same sync
    object (counter or fence), the first callback frees all SyncAwait
    structs while subsequent trigger list nodes still reference them. On the
    next iteration, reading ptl->next or ptl->pTrigger dereferences freed
    memory, leading to a use-after-free.
    
    We need separate fixes for separate issues here to fix this in one go
    - use our null-terminated list macro to make sure our next pointer stays
      valid (the code accessed ptl->next after freeing it)
    - update the list head before deleting the trigger, eventually this ends
      up being NULL anyway but meanwhile the list head is a valid list
      during CounterDestroyed
    - check if we actually do have a trigger before dereferencing the
      callback
    - Set all triggers to NULL if they are shared so we don't dereference
      potentially freed memory
    
    This vulnerability was discovered by:
    Anonymous working with TrendAI Zero Day Initiative
    
    ZDI-CAN-30159 (miSyncDestroyFence), ZDI-CAN-30163 (FreeCounter)
    
    Assisted-by: Claude:claude-opus-4-6
    (cherry picked from commit f5abfb61994471023d8c6470428c8e30c411cc0b)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2229>

commit 1888711ce4899b76fc5230e9367231c901716bb8
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Fri Apr 17 12:02:13 2026 +1000

    glx: reject negative size in FeedbackBuffer and SelectBuffer requests
    
    Assisted-by: Claude:claude-claude-opus-4-6
    (cherry picked from commit 54860e6c7f513739adf225a7998004f230db81a0)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2224>

commit 2be25deaa6a73aa9e680932065095e025019da32
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Wed May 6 11:45:15 2026 +1000

    present: actually return the created notifies
    
    present_create_notifies() creates an array of notifies but never returns
    them to the caller, despite them being passed individually to
    present_add_window_notify(). The caller proceeds with a NULL notifies
    array, eventually causing an OOB in present_vblank_notify() when
    vblank->notifies is NULL.
    
    Reported-by: Feng Ning, Innora Pte. Ltd.
    (cherry picked from commit f70cc16c6831c9faa14c1f2a8588c6efb6ede263)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2224>

commit 852bf24683d8d9fc482632582744c0e4b6791cb3
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Sat Apr 18 07:38:14 2026 +1000

    xkb: Add bounds check for action data in CheckKeyActions()
    
    CheckKeyActions() validates the per-key action count bytes individually
    but does not verify that the computed total action data region falls
    within the request buffer before advancing the wire pointer past it.
    
    After the loop, the function calculates the final wire position as
    wire + nActs * sizeof(XkbAnyAction), where nActs is the sum of per-key
    action counts read from the request. The upstream length validation in
    _XkbSetMapCheckLength() uses req->totalActs from the request header,
    not the computed nActs. If a crafted request provides a totalActs value
    that passes the length check but per-key action counts that sum to a
    different nActs, the wire pointer could advance past the actual request
    buffer.
    
    The subsequent SetKeyActions() function uses memcpy to read from this
    potentially out-of-bounds region, which could leak heap data or cause
    a crash.
    
    Assisted-by: Claude:claude-claude-opus-4-6
    (cherry picked from commit a439a7340ad976983ef34eca4f537831b38e191f)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2224>

commit 5f2ac0de4798f2290620ff89ba86af171c45013c
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Sat Apr 18 07:35:53 2026 +1000

    xkb: Fix off-by-one and NULL dereferences in _CheckSetOverlay()
    
    Off-by-one in rowUnder validation: the bounds check uses '>' instead
    of '>=' when comparing rWire->rowUnder against section->num_rows.
    Since num_rows is a count and valid indices are 0 to num_rows-1,
    rowUnder == num_rows passes the check but is one past the valid range.
    XkbAddGeomOverlayRow() uses this as an array index, causing an
    out-of-bounds read on section->rows[].
    
    And throw in two alloc checks while we're at it.
    
    Assisted-by: Claude:claude-claude-opus-4-6
    (cherry picked from commit ed19312c4bda0a8f66b236348ffc553e5d8d2a09)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2224>

commit 7ee87732a90cd557b6dd0f69b05af30e7f489b4b
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Sat Apr 18 07:35:15 2026 +1000

    xkb: Fix off-by-one in color index validation in _CheckSetGeom()
    
    The bounds checks for baseColorNdx and labelColorNdx in _CheckSetGeom()
    use '>' instead of '>=' when comparing against req->nColors. Since
    nColors is a count and valid indices are 0 to nColors-1, an index equal
    to nColors is one past the end of the array.
    
    Assisted-by: Claude:claude-claude-opus-4-6
    (cherry picked from commit 6b6e8020b902e48e3330f9a54cd439a51988bc50)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2224>

commit 39befa04f92a5acd2f97ef414a799a4a38e979d1
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Sat Apr 18 07:34:51 2026 +1000

    xkb: Fix out-of-bounds array access in _CheckSetShapes()
    
    The primaryNdx and approxNdx fields in the shape wire description are
    attacker-controlled CARD8 values from the client request. They are used
    to index into the shape->outlines[] array, but were only checked against
    XkbNoShape (0xff) and never validated against the actual number of
    outlines (shapeWire->nOutlines).
    
    Assisted-by: Claude:claude-claude-opus-4-6
    (cherry picked from commit 86a321ad98213957bbb56f295417b0939326718b)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2224>

commit c9cd39f9b7fc5a9e540ec4dbfdaafba24371851a
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Wed Apr 29 05:59:12 2026 +0000

    Xi: add missing gesture grab type checks in ProcXIPassiveUngrabDevice
    
    ProcXIPassiveUngrabDevice was missing XIGrabtypeGesturePinchBegin and
    XIGrabtypeGestureSwipeBegin from its detail!=0 rejection check. The
    corresponding ProcXIPassiveGrabDevice function correctly includes
    these gesture types.
    
    Assisted-by: Claude:claude-claude-opus-4-6
    (cherry picked from commit 90954812496770f4903a024cb610404a8dd882ad)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2224>

commit cc2bd590f368cb6aaa5d1b54e3ac4689f37f54ed
Author: Mikhail Dmitrichenko <m.dmitrichenko222@gmail.com>
Date:   Tue Apr 14 13:22:35 2026 +0300

    xkb: fix potential buff overflow in XkbVModIndexText for XkbCFile format
    
    len calculation and strncpy limit were off by one when prefixing
    "vmod_" to the virtual modifier name. This could write the final
    NULL one byte past the allocated buffer from tbGetBuffer().
    
    Use proper allocation len for prefix to avoid writing out-of-bounds.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE
    
    Signed-off-by: Mikhail Dmitrichenko <m.dmitrichenko222@gmail.com>
    (cherry picked from commit 5dfb435c1d864bf154369cb86d085d4159730378)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2224>

commit c251243f282acaf590201d8bd2508aebeb6d8fb5
Author: Mikhail Dmitrichenko <m.dmitrichenko222@gmail.com>
Date:   Tue Apr 14 12:06:51 2026 +0300

    xkb: fix incorrect size check when growing doodads in a section
    
    In XkbAddGeomDoodad(), when adding a doodad to a specific section
    (section != NULL), there is a comparison between section->num_doodads
    and geom->sz_doodads instead of the section's own section->sz_doodads.
    
    The else branch (global geometry doodads) was already correct.
    
    Compare section->num_doodads against section->sz_doodads to prevent
    a potential out-of-bounds.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Signed-off-by: Mikhail Dmitrichenko <m.dmitrichenko222@gmail.com>
    (cherry picked from commit dd8b8cf49d326802c53b01835618a7e3765d91cb)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2224>

commit 3e83c1085930d5cbd4597381d17ff7819d435299
Author: Eli Schwartz <eschwartz93@gmail.com>
Date:   Sun Jul 31 13:23:22 2022 -0400

    meson: fix types for some build options
    
    Booleans are supposed to be actual booleans, not strings describing
    their value, but Meson has a bug where it silently accepts either one.
    It's still wrong to do it though, and other implementations of Meson
    such as muon choke on it.
    
    Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
    (cherry picked from commit f5b4b79dcf6323731cae765e06c6b58fea0ce747)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2222>

commit 38efdcada1609139cb6673e1a4d0ebc8a96306f0
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Tue Apr 14 14:30:30 2026 +0200

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

commit e8674488a678387699629a0b558256cc04049ea8
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Mon Mar 2 14:09:57 2026 +0100

    xkb: Add more _XkbCheckRequestBounds()
    
    Similar to the recent fixes, add more _XkbCheckRequestBounds() to the
    functions that loop over the request data, i.e.:
    
     * CheckKeySyms()
     * CheckKeyActions()
     * CheckKeyBehaviors()
     * CheckVirtualMods()
     * CheckKeyExplicit()
     * CheckVirtualModMap()
     * _XkbSetMapChecks()
    
    All these are static functions so we can add the client to the parameters
    without breaking any API.
    
    See also:
    CVE-2026-34003, ZDI-CAN-28736, CVE-2026-34002, ZDI-CAN-28737
    
    v2: Check for "nSyms != 0" in CheckKeySyms() to avoid false positives.
    
    Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
    Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
    (cherry picked from commit d38c563fab5c4a554e0939da39e4d1dadef7cbae)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2178>

commit 905194d1fa3009c5c7f94ec0392424cd44e6a6d9
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Mon Feb 23 15:52:49 2026 +0100

    xkb: Add additional bound checking in CheckKeyTypes()
    
    The function CheckKeyTypes() will loop over the client's request but
    won't perform any additional bound checking to ensure that the data
    read remains within the request bounds.
    
    As a result, a specifically crafted request may cause CheckKeyTypes() to
    read past the request data, as reported by valgrind:
    
      == Invalid read of size 2
      ==    at 0x5A3D1D: CheckKeyTypes (xkb.c:1694)
      ==    by 0x5A6A9C: _XkbSetMapChecks (xkb.c:2515)
      ==    by 0x5A759E: ProcXkbSetMap (xkb.c:2736)
      ==    by 0x5BF832: SProcXkbSetMap (xkbSwap.c:245)
      ==    by 0x5C05ED: SProcXkbDispatch (xkbSwap.c:501)
      ==    by 0x4A20DF: Dispatch (dispatch.c:551)
      ==    by 0x4B03B4: dix_main (main.c:277)
      ==    by 0x428941: main (stubmain.c:34)
      ==  Address is 30 bytes after a block of size 28,672 in arena "client"
      ==
      == Invalid read of size 2
      ==    at 0x5A3AB6: CheckKeyTypes (xkb.c:1669)
      ==    by 0x5A6A9C: _XkbSetMapChecks (xkb.c:2515)
      ==    by 0x5A759E: ProcXkbSetMap (xkb.c:2736)
      ==    by 0x5BF832: SProcXkbSetMap (xkbSwap.c:245)
      ==    by 0x5C05ED: SProcXkbDispatch (xkbSwap.c:501)
      ==    by 0x4A20DF: Dispatch (dispatch.c:551)
      ==    by 0x4B03B4: dix_main (main.c:277)
      ==    by 0x428941: main (stubmain.c:34)
      ==  Address is 2 bytes after a block of size 28,672 alloc'd
      ==    at 0x4848897: realloc (vg_replace_malloc.c:1804)
      ==    by 0x5E357A: ReadRequestFromClient (io.c:336)
      ==    by 0x4A1FAB: Dispatch (dispatch.c:519)
      ==    by 0x4B03B4: dix_main (main.c:277)
      ==    by 0x428941: main (stubmain.c:34)
      ==
      == Invalid write of size 2
      ==    at 0x5A3AD7: CheckKeyTypes (xkb.c:1669)
      ==    by 0x5A6A9C: _XkbSetMapChecks (xkb.c:2515)
      ==    by 0x5A759E: ProcXkbSetMap (xkb.c:2736)
      ==    by 0x5BF832: SProcXkbSetMap (xkbSwap.c:245)
      ==    by 0x5C05ED: SProcXkbDispatch (xkbSwap.c:501)
      ==    by 0x4A20DF: Dispatch (dispatch.c:551)
      ==    by 0x4B03B4: dix_main (main.c:277)
      ==    by 0x428941: main (stubmain.c:34)
      ==  Address is 2 bytes after a block of size 28,672 alloc'd
      ==    at 0x4848897: realloc (vg_replace_malloc.c:1804)
      ==    by 0x5E357A: ReadRequestFromClient (io.c:336)
      ==    by 0x4A1FAB: Dispatch (dispatch.c:519)
      ==    by 0x4B03B4: dix_main (main.c:277)
      ==    by 0x428941: main (stubmain.c:34)
      ==
    
    To avoid that issue, add additional bounds checking within the loops by
    calling _XkbCheckRequestBounds() and report an error if we are to read
    past the client's request.
    
    CVE-2026-34003, ZDI-CAN-28736
    
    This vulnerability was discovered by:
    Jan-Niklas Sohn working with TrendAI Zero Day Initiative
    
    Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
    Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
    (cherry picked from commit b85b00dd7b9eee05e3c12e7ad1fce4fc6671507b)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2178>

commit 5328a544ba6c32ecdd1758283ee69058dec100f8
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Wed Feb 18 17:02:09 2026 +0100

    xkb: Fix out-of-bounds read in CheckModifierMap()
    
    As reported by valgrind:
    
      == Conditional jump or move depends on uninitialised value(s)
      ==    at 0x547E5B: CheckModifierMap (xkb.c:1972)
      ==    by 0x54A086: _XkbSetMapChecks (xkb.c:2574)
      ==    by 0x54A845: ProcXkbSetMap (xkb.c:2741)
      ==    by 0x556EF4: ProcXkbDispatch (xkb.c:7048)
      ==    by 0x454A8C: Dispatch (dispatch.c:553)
      ==    by 0x462CEB: dix_main (main.c:274)
      ==    by 0x405EA7: main (stubmain.c:34)
      ==  Uninitialised value was created by a heap allocation
      ==    at 0x4840B26: malloc (vg_replace_malloc.c:447)
      ==    by 0x592D5A: AllocateInputBuffer (io.c:981)
      ==    by 0x591F77: InsertFakeRequest (io.c:516)
      ==    by 0x45CA27: NextAvailableClient (dispatch.c:3629)
      ==    by 0x58FA81: AllocNewConnection (connection.c:628)
      ==    by 0x58FC70: EstablishNewConnections (connection.c:692)
      ==    by 0x58FFAA: HandleNotifyFd (connection.c:809)
      ==    by 0x593F42: ospoll_wait (ospoll.c:660)
      ==    by 0x58B9B6: WaitForSomething (WaitFor.c:208)
      ==    by 0x4548AC: Dispatch (dispatch.c:493)
      ==    by 0x462CEB: dix_main (main.c:274)
      ==    by 0x405EA7: main (stubmain.c:34)
    
    The issue is that the loop in CheckModifierMap() reads from wire without
    verifying that the data is within the request bounds.
    
    The req->totalModMapKeys value could exceed the actual data provided,
    causing reads of uninitialized memory.
    
    To fix that issue, we add a bounds check using _XkbCheckRequestBounds,
    but for that, we need to also pass a ClientPtr parameter, which is not
    a problem since CheckModifierMap() is a private, static function.
    
    CVE-2026-34002, ZDI-CAN-28737
    
    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 f056ce1cc96ed9261052c31524162c78e458f98c)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2178>

commit 70aad8867abdb03d8fd4fcc7405a7ee7c4666539
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Wed Feb 18 16:23:23 2026 +0100

    miext/sync: Fix use-after-free in miSyncTriggerFence()
    
    As reported by valgrind:
    
      == Invalid read of size 8
      ==    at 0x568C14: miSyncTriggerFence (misync.c:140)
      ==    by 0x540688: ProcSyncTriggerFence (sync.c:1957)
      ==    by 0x540CCC: ProcSyncDispatch (sync.c:2152)
      ==    by 0x4A28C5: Dispatch (dispatch.c:553)
      ==    by 0x4B0B24: dix_main (main.c:274)
      ==    by 0x42915E: main (stubmain.c:34)
      ==  Address 0x17e35488 is 8 bytes inside a block of size 16 free'd
      ==    at 0x4843E43: free (vg_replace_malloc.c:990)
      ==    by 0x53D683: SyncDeleteTriggerFromSyncObject (sync.c:169)
      ==    by 0x53F14D: FreeAwait (sync.c:1208)
      ==    by 0x4DFB06: doFreeResource (resource.c:888)
      ==    by 0x4DFC59: FreeResource (resource.c:918)
      ==    by 0x53E349: SyncAwaitTriggerFired (sync.c:701)
      ==    by 0x568C52: miSyncTriggerFence (misync.c:142)
      ==    by 0x540688: ProcSyncTriggerFence (sync.c:1957)
      ==    by 0x540CCC: ProcSyncDispatch (sync.c:2152)
      ==    by 0x4A28C5: Dispatch (dispatch.c:553)
      ==    by 0x4B0B24: dix_main (main.c:274)
      ==    by 0x42915E: main (stubmain.c:34)
      ==  Block was alloc'd at
      ==    at 0x4840B26: malloc (vg_replace_malloc.c:447)
      ==    by 0x5E50E1: XNFalloc (utils.c:1129)
      ==    by 0x53D772: SyncAddTriggerToSyncObject (sync.c:206)
      ==    by 0x53DCA8: SyncInitTrigger (sync.c:414)
      ==    by 0x5409C7: ProcSyncAwaitFence (sync.c:2089)
      ==    by 0x540D04: ProcSyncDispatch (sync.c:2160)
      ==    by 0x4A28C5: Dispatch (dispatch.c:553)
      ==    by 0x4B0B24: dix_main (main.c:274)
      ==    by 0x42915E: main (stubmain.c:34)
    
    When walking the list of fences to trigger, miSyncTriggerFence() may
    call TriggerFence() for the current trigger, which end up calling the
    function SyncAwaitTriggerFired().
    
    SyncAwaitTriggerFired() frees the entire await resource, which removes
    all triggers from that await - including pNext which may be another
    trigger from the same await attached to the same fence.
    
    On the next iteration, ptl = pNext points to freed memory...
    
    To avoid the issue, we need to restart the iteration from the beginning
    of the list each time a trigger fires, since the callback can modify the
    list.
    
    CVE-2026-34001, ZDI-CAN-28706
    
    This vulnerability was discovered by:
    Jan-Niklas Sohn working with TrendAI Zero Day Initiative
    
    Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
    Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
    (cherry picked from commit f19ab94ba9c891d801231654267556dc7f32b5e0)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2178>

commit a48d67f38753de551cd177e471b545bd8b9b1b64
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Wed Feb 18 16:03:11 2026 +0100

    xkb: Fix bounds check in _CheckSetGeom()
    
    As reported by valgrind:
    
      == Conditional jump or move depends on uninitialised value(s)
      ==    at 0x5CBE66: SrvXkbAddGeomKeyAlias (XKBGAlloc.c:585)
      ==    by 0x5AC7D5: _CheckSetGeom (xkb.c:5607)
      ==    by 0x5AC952: _XkbSetGeometry (xkb.c:5643)
      ==    by 0x5ACB58: ProcXkbSetGeometry (xkb.c:5684)
      ==    by 0x5B0DAC: ProcXkbDispatch (xkb.c:7070)
      ==    by 0x4A28C5: Dispatch (dispatch.c:553)
      ==    by 0x4B0B24: dix_main (main.c:274)
      ==    by 0x42915E: main (stubmain.c:34)
      ==  Uninitialised value was created by a heap allocation
      ==    at 0x4840B26: malloc (vg_replace_malloc.c:447)
      ==    by 0x5E13B0: AllocateInputBuffer (io.c:981)
      ==    by 0x5E05CD: InsertFakeRequest (io.c:516)
      ==    by 0x4AA860: NextAvailableClient (dispatch.c:3629)
      ==    by 0x5DE0D7: AllocNewConnection (connection.c:628)
      ==    by 0x5DE2C6: EstablishNewConnections (connection.c:692)
      ==    by 0x5DE600: HandleNotifyFd (connection.c:809)
      ==    by 0x5E2598: ospoll_wait (ospoll.c:660)
      ==    by 0x5DA00C: WaitForSomething (WaitFor.c:208)
      ==    by 0x4A26E5: Dispatch (dispatch.c:493)
      ==    by 0x4B0B24: dix_main (main.c:274)
      ==    by 0x42915E: main (stubmain.c:34)
    
    Each key alias entry contains two key names (the alias and the real key
    name), each of size XkbKeyNameLength.
    
    The current bounds check only validates the first name, allowing
    XkbAddGeomKeyAlias to potentially read uninitialized memory when
    accessing the second name at &wire[XkbKeyNameLength].
    
    To fix this, change the value to check to use 2 * XkbKeyNameLength to
    validate the bounds.
    
    CVE-2026-34000, ZDI-CAN-28679
    
    This vulnerability was discovered by:
    Jan-Niklas Sohn working with TrendAI Zero Day Initiative
    
    Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
    Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
    (cherry picked from commit 81b6a34f90b28c32ad499a78a4f391b7c06daea2)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2178>

commit 432cb931cf1f40cbc992916fcff716db864da1af
Author: Peter Harris <pharris2@rocketsoftware.com>
Date:   Thu Jan 15 15:54:09 2026 -0500

    xkb: fix buffer re-use in _XkbSetCompatMap
    
    If the "compat" buffer has previously been truncated, there will be
    unused space in the buffer. The code uses this space, but does not
    update the number of valid entries in the buffer.
    
    In the best case, this leads to the new compat entries being ignored. In the
    worst case, if there are any "skipped" compat entries, the number of
    valid entries will be corrupted, potentially leading to a buffer read
    overrun when processing a future request.
    
    Set the number of used "compat" entries when re-using previously
    allocated space in the buffer.
    
    CVE-2026-33999, ZDI-CAN-28593
    
    This vulnerability was discovered by:
    Jan-Niklas Sohn working with TrendAI Zero Day Initiative
    
    Signed-off-by: Peter Harris <pharris2@rocketsoftware.com>
    Acked-by: Olivier Fourdan <ofourdan@redhat.com>
    (cherry picked from commit b024ae1749ee58c6fbf863b9a1f5dc440fee2e1b)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2178>

commit fd9f9f747e1d766dea8f1a806c333d723879854a
Author: Alan Coopersmith <alan.coopersmith@oracle.com>
Date:   Tue Mar 3 13:12:12 2026 -0800

    os: fix sha1 build error with Nettle 4.0
    
    Nettle 2.6 (released in 2013) split the sha.h header into sha1.h & sha2.h,
    but left the sha.h header for compatibility until the recent Nettle 4.0
    release finally removed it.
    
    Nettle 4.0 also dropped the length argument from the sha1_digest function.
    
    Closes: #1871
    Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146>

commit 5ebf0a9dd72eaeca4713685f024ec7cab0a66961
Author: Pierre Le Marre <dev@wismill.eu>
Date:   Thu Oct 16 07:06:38 2025 +0200

    xkb: Fix serialization of key type without level names
    
    Before this commit the count of key type level names was wrongly set
    in `XkbGetNames`: for key type without names, it was set to the level
    count, while it should be 0:
    - `XkbComputeGetNamesReplySize()` does not account key type without
      level names;
    - `XkbSendNames()` does not write any level entry for key types without
      level names.
    
    This causes a mismatch offset while parsing the response and its
    processing would ultimately fail.
    
    Fixed by setting the correct level name count: 0 if there is no level
    name, else the number of levels.
    
    (cherry picked from commit c49cbc176a65892fb1109fee5c6e8316a771f5e6)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146>

commit bdc7eb8f07f2c7457de2e07ae6983e6879f21b10
Author: Pierre Le Marre <dev@wismill.eu>
Date:   Wed Oct 15 23:53:24 2025 +0200

    xkb: Fix key type without level names in XkbCopyKeymap
    
    A key type that has no level names is legit. Before this commit,
    `XkbCopyKeymap` would make such level inconsistent by setting its
    number of levels to 0 while keeping its map entries. It suffices
    to clear the names array.
    
    Fixed by copying the level count from the source type.
    
    WARNING: this will trigger an error in `XkbGetNames`, which worked
    before this commit only by chance. This is fixed in the next commit.
    
    (cherry picked from commit 12605989af6e71651c1fbb125277a953259ab7b7)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146>

commit d2f1d74f6c92a4572d03bbe7b0c734f09666197b
Author: Alexander Melnyk <inboxnumberzero@zoho.com>
Date:   Mon Dec 29 18:43:04 2025 +0200

    xkb: Fix locked/latched indicator desync across multiple keyboards
    
    When a group indicator (or a latched indicator of any kind) is defined,
    e.g.:
      indicator "Scroll Lock" { groups = Group2; }
    the logical and physical indicator state may desync across multiple
    connected keyboards.
    
    This is caused by XkbPushLockedStateToSlaves only pushing locked_mods to
    the slave devices. Pushing locked_group (as well as latched groups/mods)
    along with locked_mods resolves the issue.
    
    The issue is not observed with API calls because a different code path
    is taken (avoiding XkbPushLockedStateToSlaves altogether).
    
    Signed-off-by: Alexander Melnyk <inboxnumberzero@zoho.com>
    (cherry picked from commit 36a7fdd3152a0763636fb33a018517d831f64ee6)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146>

commit 37977717867f911985f87946dac5e89309b7c53b
Author: Alan Coopersmith <alan.coopersmith@oracle.com>
Date:   Sun Nov 2 12:16:56 2025 -0800

    glamor: avoid double free in glamor_make_pixmap_exportable()
    
    Reported by gcc 15.1:
    
    ../glamor/glamor_egl.c:320:9:
     warning: double-‘free’ of ‘modifiers’ [CWE-415] [-Wanalyzer-double-free]
    [...]
               │  732 |│        free(*modifiers);
               │      |│        ~~~~~~~~~~~~~~~~
               │      |│        |
               │      |└───────>(25) ...to here
               │      |         (26) first ‘free’ here
    [...]
        │  320 |         free(modifiers);
        │      |         ~~~~~~~~~~~~~~~
        │      |         |
        │      |         (28) ⚠️  second ‘free’ here; first ‘free’ was at (26)
    
    Fixes: cef12efc1 ("glamor: Implement GetSupportedModifiers")
    Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
    (cherry picked from commit 3e9baa20f39b0502efdaf48c2ca7e2f58d1e3120)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146>

commit b94cdc40b244f4c4d34b460511deae71891d9c9d
Author: Alan Coopersmith <alan.coopersmith@oracle.com>
Date:   Sun Nov 2 11:23:37 2025 -0800

    glamor: avoid null dereference in glamor_composite_clipped_region()
    
    Reported in #1817:
    
    xwayland-24.1.6/redhat-linux-build/../glamor/glamor_render.c:1577:21:
     warning[-Wanalyzer-null-dereference]: dereference of NULL ‘0’
    
    Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
    (cherry picked from commit 6a4ec30af49bcbf61cf8ebc3a8f5541abac9024d)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146>

commit 0ead657433437a25127ce1cf5342863fe5daaaf5
Author: Alan Coopersmith <alan.coopersmith@oracle.com>
Date:   Tue Oct 28 18:16:00 2025 -0700

    glamor: avoid null dereference in glamor_dash_setup()
    
    Reported in #1817:
    
    xwayland-24.1.6/redhat-linux-build/../glamor/glamor_dash.c:152:10:
     warning[-Wanalyzer-null-dereference]: dereference of NULL ‘0’
    
    Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
    (cherry picked from commit c6522229b86f9087347b17280b6e5f19345baf9a)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146>

commit e9d45963862b95a00d18fc27a89377e7dc4b3c92
Author: Alan Coopersmith <alan.coopersmith@oracle.com>
Date:   Sun Oct 26 15:39:47 2025 -0700

    glamor: handle allocation failures in glamor_largepixmap.c
    
    Reported in #1817:
    
    xwayland-24.1.6/redhat-linux-build/../glamor/glamor_largepixmap.c:130:17:
     warning[-Wanalyzer-possible-null-dereference]:
      dereference of possibly-NULL ‘clipped_regions’
    
    xwayland-24.1.6/redhat-linux-build/../glamor/glamor_largepixmap.c:235:13:
     warning[-Wanalyzer-possible-null-dereference]:
      dereference of possibly-NULL ‘result_regions’
    
    xwayland-24.1.6/redhat-linux-build/../glamor/glamor_largepixmap.c:365:9:
     warning[-Wanalyzer-possible-null-dereference]:
      dereference of possibly-NULL ‘clipped_regions’
    
    xwayland-24.1.6/redhat-linux-build/../glamor/glamor_largepixmap.c:1175:9:
     warning[-Wanalyzer-possible-null-dereference]:
      dereference of possibly-NULL ‘source_pixmap_priv’
    
    Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
    (cherry picked from commit 84cf20e6ddacbfc62637f156a92d673574c43604)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146>

commit 733eab332c8a6ec16cfc45cceeccddd66378c130
Author: Alan Coopersmith <alan.coopersmith@oracle.com>
Date:   Sun Oct 26 12:56:13 2025 -0700

    glamor: silence false positive in glamor_validate_gc()
    
    We know that if gc->tileIsPixel is false, then gc->tile.pixmap must be
    a valid pixmap, but gcc's static analyzer doesn't and needs to be told.
    
    Silences false positive reported in #1817:
    
    xwayland-24.1.6/redhat-linux-build/../glamor/glamor_core.c:205:19:
     warning[-Wanalyzer-null-dereference]: dereference of NULL ‘0’
    
    Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
    (cherry picked from commit a79bdc495eaabd770cec03badd74c3b023877ba1)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146>

commit b00201506a9d973b45efc6f7b74bb6628b9e2b8f
Author: Alan Coopersmith <alan.coopersmith@oracle.com>
Date:   Sat Oct 25 16:27:34 2025 -0700

    glamor: handle allocation failure in glamor_create_pixmap()
    
    Reported by gcc 15.1:
    
    ../glamor/glamor.c: In function ‘glamor_create_pixmap’:
    ../glamor/glamor.c:233:23: warning: potential null pointer dereference
     [-Wnull-dereference]
      233 |     pixmap_priv->type = GLAMOR_TEXTURE_ONLY;
          |     ~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
    ../glamor/glamor.c:228:26: warning: potential null pointer dereference
     [-Wnull-dereference]
