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 bb5158f962)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2230>
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 ecc634f1b2)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2230>
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 402b329c3a ("glx: Work around
wrong request lengths sent by mesa"). This was fixed in mesa commit
4324d6fdfbba1 in 2011 (mesa 7.11).
Fixes: 402b329c3a ("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 6d459e4daf)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2230>
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 867b59b33b)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2230>
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 543e108516)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2230>
This is the equivalent check to miSyncTriggerFence() from
commit f19ab94ba9 ("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 bdd7bf57af)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2230>
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 f5abfb6199)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2230>
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 f70cc16c68)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2225>
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 a439a7340a)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2225>
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 ed19312c4b)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2225>
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 6b6e8020b9)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2225>
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 86a321ad98)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2225>
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 9095481249)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2225>
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 5dfb435c1d)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2225>
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 dd8b8cf49d)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2225>
Commit 34934c37d6 restored calling register_damage() in
xwl_realize_window() before ensure_surface_for_window().
However if register_damage() succeeds and ensure_surface_for_window()
returns NULL, it would exit without "unregistering" the damage hook.
The X11 window, however, may still get damages reports, in which case
xwl_window_from_window() would return NULL, causing a NULL pointer
dereference in damage_report().
To avoid the issue, make sure we unregister the damage report if
ensure_surface_for_window() has failed, and add an early exit in
damage_report() if xwl_window is NULL.
v2: unregister_damage() unconditionally if ensure_surface_for_window()
failed (Michel Dänzer)
Fixes: commit 34934c37d6 ("revert: register damage before ensure_surface_for_window")
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/work_items/1886
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit 36f53145e4)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2191>
Commit 0e08e5083 ("xwayland: prevent X11 get enter event when pointer is
over Wayland client") introduced a pointer crossing count to avoid
sending spurious pointer enter events when the pointer is within a
Wayland native surface.
However, that change breaks tablet devices, as the pointer enter count
is only updated from the wl_pointer enter/leave events, a slave X11
device such as a tablet pointer would report a lost focus and the event
wrongly sent to the root window.
To avoid the issue, revert partially commit 0e08e5083 to return FALSE
as before for the slave devices. The rest of the logic from commit
0e08e5083 remains unchanged, so that we do not send spurious
XCrossingEvents for the pointer device when it's within a native Wayland
surface.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/work_items/1884
(cherry picked from commit c39b1591b2)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2179>
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 d38c563fab)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2177>
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 b85b00dd7b)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2177>
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 f056ce1cc9)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2177>
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 f19ab94ba9)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2177>
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 81b6a34f90)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2177>
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 b024ae1749)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2177>
When Xwayland is used rootful with hidpi, a viewport is in effect and a
scale applied.
This is however "transparent" to the Xserver which uses unscaled
coordinates, so to set the fake cursor position with a viewport and a
scale applied, we need to factor the scale to the coordinates before
passing the coordinate to the Wayland compositor through the method
zwp_locked_pointer_v1_set_cursor_position_hint().
Failing to do that will introduce a shift when warping the cursor
position.
v2: Use an xwl_window instead of an xwl_seat to improve readability
(Michel)
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1875
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit 0e580872b0)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2151>
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>
(cherry picked from commit f8355b8821)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2151>
There've been reports downstream of Xwayland segfaulting in the function
xwl_present_execute() because xwl_window_get_damage_region() returned an
invalid pointer:
#10 RegionUninit at ../include/regionstr.h:165
#11 RegionEmpty at ../include/regionstr.h:194
#12 xwl_present_execute at ../hw/xwayland/xwayland-present.c:1138
#13 xwl_present_pixmap at ../hw/xwayland/xwayland-present.c:1274
#14 present_pixmap at ../present/present.c:249
#15 proc_present_pixmap_common at ../present/present_request.c:166
#16 proc_present_pixmap at ../present/present_request.c:186
#17 Dispatch at ../dix/dispatch.c:550
#18 dix_main at ../dix/main.c:277
The most likely reason for this is that window_get_damage() returned
NULL, which might happen if xwl_window_update_surface_window() didn't
call register_damage().
To avoid that issue, move the call to register_damage() back to
xwl_realize_window before calling ensure_surface_for_window().
This reverts commit 07f6032627.
See-also: https://bugzilla.redhat.com/2329815
See-also: https://bugzilla.redhat.com/2428249
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1862
Signed-off-by: Michel Dänzer <mdaenzer@redhat.com>
(cherry picked from commit c76d495612)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2151>
This fix use after free when a pluggable gpu screen (such as displaylink)
was set as primary screen and unpluged.
gdb backtrace:
#0 OssigHandler (signo=11, sip=0x7fff2e0a50f0, unused=0x7fff2e0a4fc0) at ../../../../os/osinit.c:138
#1 <signal handler called>
#2 rrGetscreenResources (client=0x3195160, query=0) at ../../../../randr/rrscreen.c:577
#3 0x0000000000562bae in ProcRRGetscreenResourcesCurrent (client=0x3195160) at ../../../../randr/rrscreen.c:652
#4 OxOOOOB0000054de63 in ProcRRDispatch (client=0x3195160) at ../../../../randr/randr.c:717
#5 0x00000000004322c6 in Dispatch () at ../../../../dix/dispatch.c:485
#6 0x0900900990443139 in dix_main (argc=12, argv=0x7fff2e0a5f78, envp=0x7fff2e0a5fe0) at ../../../../dix/main.c:276
#7 0X0000000000421d9a in main (argc=12, argv=0x7fff2e0a5f78, envp=0x7fff2e0a5fe0) at ../../../../dix/stubmain.c:34
Signed-off-by: hongao <hongao@uniontech.com>
(cherry picked from commit 1443fd34ea)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2151>
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 c49cbc176a)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2151>
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 12605989af)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2151>
the license notice comes from these files:
- dix/registry.c
- Xext/xselinuxint.h
- Xext/xselinux_label.c
- Xext/xselinux_hooks.c
- Xext/xselinux_ext.c
- Xext/xselinux.h
- Xext/xacestr.h
- Xext/xace.h
- Xext/xace.c
while this is not like the standard `Copyright (C)` lines I think it
still belongs to the license, even if just to make it more clearly
separate from the MIT license above
(cherry picked from commit fff0023339)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2151>
In the `doListFontsAndAliases` function in dixfonts.c, when a font alias
is encountered (`err == FontNameAlias`) as a result of
`list_next_font_or_alias` call, the code allocates memory for
`resolved` variable (`resolvedlen + 1` bytes) for storing target font
name. In this case, if the `malloc(resolvedlen + 1)` call fails,
`resolved` remains NULL.
Later, when check (`else if (err == FontNameAlias)`) is TRUE, the code
uses `memcpy` to copy nullable `resolved` into `tmp_pattern` without
checking if `resolved` is NULL, so there is a potential null ptr
dereference.
This commit replaces `malloc` with `XNFalloc` for allocating memory for
`resolved`. `XNFalloc` will internally check result of `malloc` and stop
program execution if allocation was failed, preventing potential NULL
dereferencing.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Mikhail Dmitrichenko <m.dmitrichenko222@gmail.com>
(cherry picked from commit 0237462d32)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2151>
Free nested allocations when initialization fails.
Several code paths returned early on error without releasing
memory owned by embedded structures, leading to leaks.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Mikhail Dmitrichenko <m.dmitrichenko222@gmail.com>
(cherry picked from commit 809402414e)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2151>
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 36a7fdd315)
(cherry picked from commit a9ee6b7326)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2151>
In Wayland, mouse coordinates are not updated after all x11 clients have left,
causing the mouse information to remain at the position left by the last x11
client. However, if CheckMotion is called at this point for other reasons
(such as window mapped, reactive, etc.), xwayland might continue to send enter
events to x11 clients, even if the mouse is actually on a Wayland client.
This MR introduces and checks pointer_enter_count to determine if the mouse
has left an x11 client and is now on a Wayland client. When it's confirmed
that the mouse is no longer on an x11 client but on a Wayland client,
returning TRUE in sprite_check_lost_focus causes XYToWindow to return to the
root window, preventing further enter events from being sent to x11 clients.
(cherry picked from commit e673a4bda0)
(cherry picked from commit 6bef11002f)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2151>
When compiling with gcc 15.2.0 using -O3 -m64 on Solaris SPARC & x64,
we'd get a test failure of:
Assertion failed: strcmp(logmsg, expected) == 0,
file ../test/signal-logging.c, line 339, function logging_format
because 'num *= 1' produced a value that was out of the range of the
int64_t it was being stored in. (Compiling with -O2 worked fine with
the same compiler/configuration/platform though.)
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
(cherry picked from commit 7f68b58865)
(cherry picked from commit 3eac9393d7)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2151>
In `Fopen` function variable `iop` may store NULL as a result of `fopen`
call. In this case, if later privileges couldn't be restored (`seteuid`
call fails), further `fclose(iop)` call will cause runtime error.
This commit adds check `iop` for NULL before calling `fclose` to prevent
potential NULL pointer dereference.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Mikhail Dmitrichenko <m.dmitrichenko222@gmail.com>
(cherry picked from commit f83807647e)
(cherry picked from commit dd2255c309)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2151>
Xwayland was sending incorrect pointer coordinates to X clients on
pointer enter events.
This was caused by calling CheckMotion() with a NULL event, which
prevented the pointer sprite hot coordinates from being updated
properly.
Fix this by constructing a proper DeviceEvent of type ET_Enter in
pointer_handle_enter, initializing it with the current timestamp
and EVENT_SOURCE_FOCUS, and passing it to CheckMotion() instead
of NULL.
This ensures the pointer sprite coordinates are correctly updated
when the pointer enters a window.
(cherry picked from commit 7fb5e00ad8)
(cherry picked from commit b4c5796e4b)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2151>
dixLookupResourceByType always overwrites the pointer passed in as the
first arg, so we shouldn't use the union it's in after that to get the
requested XID value to put in the errorValue.
Closes: #1857
Fixes: 2d7eb4a19 ("Pre-validate ChangeGC XIDs.")
Reported-by: Mouse <mouse@Rodents-Montreal.ORG>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
(cherry picked from commit ac42c39145)
(cherry picked from commit 7f1050de78)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2151>
