commit 65d790bd208ec380b196eb98f144abb0b32e334d
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Wed Jul 8 11:21:12 2026 +1000

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

commit f3df3c9a52b4f480cbcff45cc6569c19de6bfede
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Sun May 31 19:37:01 2026 +1000

    glamor: reject fonts with per-glyph metrics exceeding maxbounds
    
    glamor_font_get() computes the atlas slot size from the font's declared
    maxbounds, but copies each glyph's bitmap using the per-glyph metrics
    (GLYPHHEIGHTPIXELS/GLYPHWIDTHBYTES macros). When a malicious PCF font
    has per-glyph metrics exceeding maxbounds, the memcpy writes past the
    heap-allocated atlas buffer. Negative per-glyph metrics are even worse:
    the loop counter wraps to ~4 billion iterations (via unsigned cast) or
    memcpy's size parameter wraps to SIZE_MAX.
    
    The PCF parser in libXfont2 does not recompute maxbounds from per-glyph
    data (only the BDF parser does), so the file's declared maxbounds values
    are trusted as-is.
    
    Reject fonts where any per-glyph metric is negative or exceeds the
    atlas slot size, falling back to software rendering which uses per-glyph
    metrics directly without an atlas.
    
    This vulnerability was discovered by:
    Anonymous working with Trend Micro Zero Day Initiative
    
    CVE-2026-55999/ZDI-CAN-30498
    
    Assisted-by: Claude:claude-opus-4-6
    (cherry picked from commit fbf7bac22e2c6bd627fb042742a23318263edae1)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2252>

commit 0f1f4bcbfb1f23b800dfe386782d3a0f05b6756f
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Mon Jun 1 20:44:34 2026 +1000

    fb/mi/glamor: reject glyphs with negative dimensions
    
    GLYPHWIDTHPIXELS and GLYPHHEIGHTPIXELS compute glyph dimensions from
    signed INT16 fields. A crafted PCF font can produce negative results
    (e.g. rightSideBearing < leftSideBearing).
    
    All callees have a while (height--) loop which will end up in OOB writes
    for negative height values.
    
    In the case of a negative height, some callees cast to size_t or end up
    with negative strides.
    
    The same pattern exists in fbPoloyGlyphBit, miPolyGlyphBlt and
    glamor_poly_glyph_blt_gl, so let's fix all of them in one go.
    
    Assisted-by: Claude:claude-opus-4-6
    (cherry picked from commit e31efd3e106e53bfc29d499ff0a34b0d20013f2d)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2252>

commit d6d96084f305a142eb3db7f720d7edd21e4c98b4
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Sun May 31 19:37:02 2026 +1000

    glx: free old context tag before allocating new one in CommonMakeCurrent
    
    oldTag in CommonMakeCurrent() is a pointer to cl->contextTags[...].
    CommonMakeCurrent() may realloc(cl->contextTags) and thus move the
    memory, leaving oldTag as dangling pointer.
    
    If we then GlxFreeContextTag(oldTag) we end up writing into freed
    memory.
    
    Fix this by freeing oldTag before CommonMakeNewCurrent().
    
    This vulnerability was discovered by:
    Anonymous working with Trend Micro Zero Day Initiative
    
    CVE-2026-56000/ZDI-CAN-30561
    
    Fixes: 4781f2a5a8c2 ("GLX: Free the tag of the old context later")
    Assisted-by: Claude:claude-opus-4-6
    (cherry picked from commit 2779affbdb4354e894f490e56f962527d6125043)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2252>

commit d6fff22bc8b464dbadf3bc1fb858bd5a91c86849
Author: Doğukan Korkmaztürk <dkorkmazturk@nvidia.com>
Date:   Tue Nov 22 13:43:16 2022 -0500

    GLX: Free the tag of the old context later
    
    In CommonMakeCurrent() function, the tag of the old context is freed
    before the new context is made current. This is problematic because if
    the CommonMakeNewCurrent() function fails, the tag of the old context
    ends up being removed, even though it is still active. This causes
    subsequent glXMakeCurrent() or glXMakeContextCurrent() requests to
    generate a GLXBadContextTag error.
    
    This change moves the function call that frees the old tag to a location
    where the result of CommonMakeNewCurrent() call is known and it is safe
    to free it.
    
    Signed-off-by: Doğukan Korkmaztürk <dkorkmazturk@nvidia.com>
    (cherry picked from commit 4781f2a5a8c2c2b000374e2d87982a6701d5a6b3)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2252>

commit ab2766f3473efdc9d13234553d21b0dc4dd780d8
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Tue Jun 23 14:10:44 2026 +0200

    Xi: Check window attribute is valid in XIChangeCursor
    
    The XInput2 request XIChangeCursor() does not specify whether the window
    attribute can be NULL, nor does the code in ProcXIChangeCursor().
    
    As a result, if the window is NULL, the xserver ends up dereferencing a
    NULL pointer and segfaults.
    
    To avoid the issue, check the actual value passed for the window and
    return a BadWindow error if the window was not specified.
    
    Please note that particular error is however not documented in the XI2
    protocol definition [1], yet that seems to be the only sane course of
    action, reading the definition of XIChangeCursor(), a valid window is
    to be expected.
    
    [1] https://xorg.freedesktop.org/archive/current/doc/inputproto/XI2proto.txt
    
    (cherry picked from commit 7aac5d4dc6bc934b7cae40afdfd98261a8e80427)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2247>

commit c0839d9cbf85261cea20cda2f7d6c8a732e16eb6
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Wed Jun 17 16:50:34 2026 +0200

    dix: Silence a compiler warning in doListFontsWithInfo()
    
    Static analyzer reports:
    
    | dix/dixfonts.c:936:17: uninit_use_in_call: Using uninitialized value "name" when calling "memcpy".
    |   934|                   free(c->savedName);
    |   935|                   c->savedName = XNFalloc(namelen + 1);
    |   936|->                 memcpy(c->savedName, name, namelen + 1);
    |   937|                   aliascount = 20;
    |   938|               }
    
    To silence the warning, we cannot just set "name" to NULL, as this could
    potentially cause a NULL pointer in memcpy(), we also need to check if
    the value was set. If not, just bail out with a BadFontNAme error.
    
    Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
    (cherry picked from commit 5d011bf3da81595bef25ca89458249c1037a4f51)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2247>

commit bf25faf5c1b825f14642f81129b28e04a024356d
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Tue Apr 28 11:06:27 2026 +0200

    dix: Silent static analyzer warning
    
     | dix/dixfonts.c:849:5: var_decl: Declaring variable "namelen" without initializer.
     | dix/dixfonts.c:932:17: uninit_use: Using uninitialized value "namelen".
     |    930|                   c->savedNumFonts = numFonts;
     |    931|                   free(c->savedName);
     |    932|->                 c->savedName = XNFalloc(namelen + 1);
     |    933|                   memcpy(c->savedName
    
    (cherry picked from commit f959f1e51f369ac26b6ba5953a3b022407e85b11)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2247>

commit 6c6a2dfd295f836a502410ff40b5855b133c7ffd
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Mon Jun 15 14:00:19 2026 +0200

    dix: Silence a compiler warning in doListFontsAndAliases()
    
    Compiler complains that "resolvedlen" might be uninitialized:
    
    | dix/dixfonts.c:559:5: var_decl: Declaring variable "resolvedlen" without initializer.
    | dix/dixfonts.c:674:17: uninit_use: Using uninitialized value "resolvedlen".
    |    672|                    * is complete.
    |    673|                    */
    |    674|->                 if (resolvedlen > XLFDMAXFONTNAMELEN) {
    |    675|                       err = BadFontName;
    |    676|                       goto ContBadFontName;
    
    Most likely a false positive, while immediately after the (newly added)
    test, there was a memcpy() using "resolvedlen" and the compiler did not
    choke on that before.
    
    Either way, initializing "resolvedlen" to 0 is a small price to pay to
    silence the compiler warning and keep us on the safe side.
    
    Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
    (cherry picked from commit e710e570b1709d100072a8ab7d05c2aefaf41a1b)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2247>

commit f2f7b8293c1f3594b31301159c7ddf4570ea9a7f
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Tue Jun 2 13:08:37 2026 +1000

    glamor: fix an error path cleanup
    
    The GL_OUT_OF_MEMORY error path returns NULL without freeing the
    allocated `bits` buffer or deleting the GL texture.
    
    Assisted-by: Claude:claude-opus-4-6
    (cherry picked from commit 174aac67c99cb7ac26acb6613831c6db0ebd549f)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2247>

commit c285ed7dc6e429e7747f76c208f9a373261421f8
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Mon Jun 1 21:01:58 2026 +1000

    glx: fix duplicate tagInfo->vendor = NULL assignment
    
    Assisted-by: Claude:claude-opus-4-6
    (cherry picked from commit 66c4a2a6af70112295a5e163fe75a78d29bd3137)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2247>

commit a29a7c1ec5b488b4069ef976e8096cb997074e49
Author: Mikhail Dmitrichenko <m.dmitrichenko222@gmail.com>
Date:   Mon May 25 12:46:28 2026 +0300

    xkb: preserve buffer on realloc failure
    
    _Concat() stored the realloc() result directly in its input pointer, so
    an allocation failure could drop the only reference to the original
    buffer when callers assigned the return value back to their destination
    pointer.
    
    Keep the old pointer until realloc() succeeds, avoiding the leak
    reported by static analysis.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Signed-off-by: Mikhail Dmitrichenko <m.dmitrichenko222@gmail.com>
    (cherry picked from commit d6c462f59927b3702a54e0e8ea2a5de7639294e6)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2247>

commit 8a6e5f0fcdf196bd5ba2059816069806d523b665
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Fri Apr 17 10:13:51 2026 +1000

    dix/colormap: fix out-of-bounds read in FindColorInRootCmap
    
    The for loop here always iterates size times but the client controls the
    starting offset. When the starting pixel is non-zero (e.g., pixel=10 in
    a size=256 colormap), the loop reads from pentFirst[10] through
    pentFirst[265], reading 10 entries past the end of the array.
    
    Fix this by wrapping around once we reach size, same as FindColor()
    already does.
    
    Assisted-by: Claude:claude-claude-opus-4-6
    (cherry picked from commit b4f2807a40fb0b149f475f3e459a3a38fd114096)
    
    Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2247>

commit b0be3a9e5a6f96709157f0d58c03557e53ab9a58
Author: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Date:   Wed Jul 1 08:55:33 2026 -0700

    xquartz/GL: advertise GLX_ARB_create_context and _profile
    
    XQuartz never called __glXEnableExtension for GLX_ARB_create_context or its
    profile / robustness companions, so clients could not use
    glXCreateContextAttribsARB to ask for a specific OpenGL version or profile.
    
    Enable the three extensions in __glXAquaScreenProbe between the
    InitExtensionEnableBits call and __glXScreenInit so the extension string
    picks them up.  The direct-rendering path (XQuartz's AppleDRI mode) does
    not go through __glXAquaScreenCreateContext -- createcontext.c routes
    direct requests to __glXdirectContextCreate, and the actual context is
    built on the client side.  The server-side createContext hook stays
    capped at GL 1.4 for indirect clients by validate_GL_version and does not
    need changes.
    
    This is needed for OpenGL core profile support.
    
    Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
    (cherry picked from commit 609e7d9421f5fcb51e6071a0f189cc725a6c5714)

commit 834b406744483ed07f54a35f4036462c76c79545
Author: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Date:   Wed Jul 1 08:54:29 2026 -0700

    xquartz/GL: silence OpenGL deprecation warnings
    
    OpenGL.framework and CGL are annotated OPENGL_DEPRECATED(_, 10.14) in the SDK,
    but that can be silenced with -DGL_SILENCE_DEPRECATION.
    
    Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
    (cherry picked from commit 31060c9506b41a6082a25c3368c9dede08fc5a89)

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().
    
