The sparc64 QEMU job installs the server, builds the six sun* drivers
from their tags and runs check-symbols.sh on each module.
Signed-off-by: Joseph Crowell <joseph.w.crowell@gmail.com>
The SBUS API they use is built into the server only on SPARC, so x86
driver jobs only compile them; the sparc64 job checks them.
Signed-off-by: Joseph Crowell <joseph.w.crowell@gmail.com>
Each module that fails check-symbols.sh, or a driver that built none,
becomes an error annotation naming it and its missing symbols, so they
show at the top of the run and in the failure notification.
Signed-off-by: Joseph Crowell <joseph.w.crowell@gmail.com>
ldd now searches the server's libdir, so libraries installed with the
server (libdrm in CI) are not reported as missing server symbols, and a
library still not found exits 2. One failing driver job no longer
cancels the others.
Signed-off-by: Joseph Crowell <joseph.w.crowell@gmail.com>
Each driver job runs check-symbols.sh on the modules it built and
fails when the server does not export a symbol they need. Changes
to abi/ or the driver build script now run the driver jobs.
Signed-off-by: Joseph Crowell <joseph.w.crowell@gmail.com>
A module linked with -z now must resolve every symbol at dlopen(),
before the modules it loads itself exist, so report the symbols only
other modules define and suggest -z lazy.
Signed-off-by: Joseph Crowell <joseph.w.crowell@gmail.com>
On forks it tried to comment on upstream PRs with the fork's token
and failed on every push to master.
Signed-off-by: Joseph Crowell <joseph.w.crowell@gmail.com>
With --prefix <dir>, check a module against the Xorg in <dir>/bin and
the module directory from the xorg-server.pc pkg-config finds, so CI
jobs with an installed server can run the check.
Signed-off-by: Joseph Crowell <joseph.w.crowell@gmail.com>
A fork PR's token cannot push to ghcr.io, so build-sdk-image failed and
the driver builds were skipped. On fork PRs, pass /opt/x11 from the
built SDK image as an artifact and unpack it over the deps image.
Signed-off-by: Joseph Crowell <joseph.w.crowell@gmail.com>
Ship the libabigail and symbol checks drivers use, so every driver can
test itself against staged servers; find them with pkg-config
--variable=abi_tools_dir xorg-server.
Signed-off-by: Joseph Crowell <joseph.w.crowell@gmail.com>
Ubuntu 26.04 runners have no qemu-user-static: qemu-user ships the
static binaries without the -static suffix and qemu-user-binfmt
registers them. Fall back to those and copy the registered binary.
Signed-off-by: Joseph Crowell <joseph.w.crowell@gmail.com>
xgi 25.0.0 does not build with GCC 15 (C23 bool, incompatible pointer
types); 25.0.1 has the fixes.
Signed-off-by: Joseph Crowell <joseph.w.crowell@gmail.com>
The xorg commit da72833185 which had been
cherry-picked introduces a new field in the middle of the DamageRec struct,
which is part of the public driver ABI.
It broke at least the amdgpu driver (at time of writing no others known yet)
So doing what's the correct approach here: always put new fields at the
end of the struct, never change existing layout.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
`sizeof` was incorrectly used to get the length of an string in an array
of char pointers (array of strings), which always returns the system's
pointer size (8 on 64bit) instead of the actual string length.
Was fixed by using `strlen` instead.
Additionally the final step that appended the returning array of strings
with another array of strings, also used an incorrect `memcpy` function
to copy the elements.
Was fixed by using an explicit for loop.
And I also replaced the 'length' variables' type's with the proper
`size_t` type instead of `int`, where possible.
Issue and patch from:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=299077
Signed-off-by: b-aaz <b-aazbsd@proton.me>
gen_gl_wrappers.py imports lxml.etree at build time, but Cygwin CI only
installed python312-lxml (for Python 3.12) while the default Python is
python39. Add python39-lxml so the import succeeds under Cygwin.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
These code pathes have never been actually used, thus no need to
carry them around for any longer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
* didn't compile since 2014 (commit 21b216ad6)
* based on vm86(), which is only availble on Linux i386/i686
* obsoleted by x86emu
Thus no need to carry around broken code pathes any longer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It seems that ancient DG/UX systems needed some special workarounds,
which of we only have some remains left that are never compiled.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
input_constrain_cursor() writes barrier hit and leave events into the
InputEventList buffer without checking how many slots remain.
The buffer is allocated by the DDX at GetMaximumEventsNum() (100) entries
and may contain one raw event already. A client can create more than 100
pointer barriers, pre-arm them as released via XIBarrierReleasePointer,
and then trigger a single pointer motion that crosses all barriers
simultaneously. The leave event loop iterates every hit barrier and
writes one event per barrier, overflowing the 100-slot buffer.
In an ideal world we'd change the InternalEvent* pointer to a struct
that contains allocated size, number of events and the pointer itself
but we're crossing public APIs here and that requires an ABI bump.
So we make do with cutting off the number of barrier events at 64 which
should be low enough to not trigger the issue. However, for the 100+
barrier case this means we only send BarierHit events, not BarrierRelease.
Potentially leaving a client stuck.
We mitigate that problem by simply refusing to create more than 32
barriers per screen (which on its own would also fix the issue, but hey,
'doppelt gemoppelt' as they say).
This vulnerability was discovered by:
Anonymous working with TrendAI Zero Day Initiative
ZDI-CAN-31938
CVE-2026-93519
Assisted-by: Claude:claude-opus-4-6
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2341>
(cherry picked from commit 1f42cc1f00)
Passive grabs (GrabRec) store raw DeviceIntPtr values for both the
grabbed device and the modifier device without any lifetime management.
When a device is removed via XIRemoveMaster, CloseDevice() frees the
device struct, but leaves dangling pointers in grab->modifierDevice
for any grab that used this device.
Subsequent pointer events trigger CheckPassiveGrab() which dereferences
the dangling modifierDevice pointer for XI grabs (the CORE and XI2 paths
reassign it, but the XI path does not).
This vulnerability was discovered by:
Anonymous working with TrendAI Zero Day Initiative
ZDI-CAN-31832
CVE-2026-93516
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2341>
(cherry picked from commit be57263415)
ProcXIPassiveUngrabDevice() passes client-supplied modifier values
directly to DeletePassiveGrabFromList() without validating them.
DeletePassiveGrabFromList() may reach DeleteDetailFromMask() which uses
BITCLEAR(mask, modifier). The mask is allocated as 8 Mask words (256
bits). A modifier value > 255 causes BITCLEAR to index mask[modifier>>5]
past the allocation, resulting in a controlled single-bit-clear at an
attacker-chosen heap offset.
Add the same modifier validation that CheckGrabValues() uses: reject
modifiers that are not XIAnyModifier and have bits set outside
AllModifiersMask.
This vulnerability was discovered by:
Anonymous working with TrendAI Zero Day Initiative
ZDI-CAN-32366
CVE-2026-93523
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2341>
(cherry picked from commit 37a1847a60)
Since commit a94dd9536 ("modesetting: add support for TearFree page flips"),
whenever TearFree and PageFlip is simultaneously enabled (which is the
default now), the driver does enable DRM universal plane support, just
as when atomic modesetting is enabled.
Leasing RandR / DRM outputs with universal planes enabled requires
also adding the drm_plane object to the set of leased objects,
otherwise the drmModeCreateLease() ioctl will fail.
Adding a drm_plane object under this condition was omitted, so fix
this omission, and thereby fix RandR output leasing.
Fixes: a94dd9536 ("modesetting: add support for TearFree page flips")
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2332>
(cherry picked from commit f37bd8de26)
Two if conditions compressed into one.
Two open() marked as ignored by SIM115 (use context manager for opening files)
because it'd require too much restructuring.
And one open() ... close() changed to a context manager, the diff
is the reindentation of everything between open and close.
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2327>
(cherry picked from commit eb9292efdb)
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is still Python2 which has been EOL for many moons now. The script
dates back to 2010 and we've well and truly moved on from using fdi files
to using xorg.conf snippets.
If in the last 16 years you somehow didn't manage to port the fdi
snippets, the git history will provide you with this file on request.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2327>
(cherry picked from commit f8af92cac4)
CheckKeySyms() has two loops: the first processes keys in the SetMap
request range, the second fills in any missing keys from the existing
map.
The indexing between the two was inconsistent: the first loop
uses a zero-based index + req->firstKeySym, the second loop used it just
as zero-based index.
Example:
req->firstKeySym = 50
req->nKeySyms = 10
i goes from 0 to 10,
loop 1 checks [50, 60), changes the width but finishes with i at 10.
loop 2 then runs over [10, 255(, copying the old keymap width
The second loop overwrites the new widths with the width of the
existing keymap. The subsequent SetKeySyms worked on the new width
and may write fewer actions than the map width.
A subsequent XkbGetMap request would then read XkbKeyNumActions()
entries (derived from the new wider key_sym_map.width) from the shorter
action allocation, causing an out-of-bounds heap read. The overread
bytes would be copied into the GetMap reply and sent back to the client,
producing a bounded heap information disclosure.
This vulnerability was discovered by:
WONJOON HWANG (@joon1337) working with TrendAI Zero Day Initiative
ZDI-CAN-32408
CVE-2026-93524
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2341>
(cherry picked from commit cea71d0273)
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Fields in XkbClientMapRec and XkbServerMapRec that denote size/num
and are unsigned short can result in truncations. For example
when XkbResizeKeyType() computes the new size_syms value as
(nTotal * 15) / 10, the result may be implicitly truncated to 16
bits on assignment. This causes an undersized calloc allocation, and the
subsequent copy loop writes based on the actual (untruncated) key count,
resulting in a heap buffer overflow. A similar truncation may happen
in XkbResizeKeySyms() and XkbResizeKeyActions().
Widen the fields from unsigned short to unsigned int. These are internal
server structures, not wire protocol types.
This vulnerability was discovered by:
Anonymous working with TrendAI Zero Day Initiative
ZDI-CAN-31834
CVE-2026-93518
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2341>
(cherry picked from commit 89101a6c66)
Commit a3171732d ("xkb: Always use MAP_LENGTH keymap size") converted
most XKB allocation functions to use MAP_LENGTH (256) instead of
max_key_code + 1. It also removed the per-array reallocarray() calls in
XkbChangeKeycodeRange(), replacing them with a memset up to MAP_LENGTH.
However, XkbAllocNames() was missed and still allocates names->keys to
max_key_code + 1.
When a keycodes component with max_key_code < 255 is loaded (e.g.
sun(type6) with max_key_code=132) and then a SetMap request extends
maxKeyCode to 255, XkbChangeKeycodeRange() memsets names->keys from
max_key_code to MAP_LENGTH-1, writing past the undersized allocation.
Fix by allocating names->keys to MAP_LENGTH, consistent with all other
keymap arrays after a3171732d.
This vulnerability was discovered by:
Anonymous working with TrendAI Zero Day Initiative
ZDI-CAN-31941
CVE-2026-93520
Fixes: a3171732da ("xkb: Always use MAP_LENGTH keymap size")
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2341>
(cherry picked from commit b941a473e0)
_CheckSetDoodad() allocates doodad->text.text via _GetCountedString()
and then attempts to allocate doodad->text.font. If the font string
allocation fails (e.g. because the font string length extends past
the request boundary), the error handler frees doodad->text.text but
does not NULL the pointer. The doodad was already added to the geometry
by XkbAddGeomDoodad() before the string allocations, so when
XkbFreeGeometry() runs cleanup, _XkbClearDoodad() frees the same
dangling pointer again, resulting in a double-free.
NULL the pointer after freeing it to prevent the double-free.
This vulnerability was discovered by:
Anonymous working with TrendAI Zero Day Initiative
ZDI-CAN-31221
CVE-2026-88812
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2341>
(cherry picked from commit 0d1b1b0bad)
XkmReadFile() allocates an XkbDesc before it reads the individual XKM
sections, so a section read failure leaves a non-NULL but only partially
initialized description behind.
ReadXkmKeyTypes() does not report such a failure at all. When
XkbAllocClientMap() fails it returns the number of bytes read so far,
which is positive, so XkmReadFile() takes the section for successfully
read and clears it from the mask of sections it reports as missing.
ProcXkbGetKbdByName() in turn only checks that the description it got
back is non-NULL before setting rep.loaded. It can therefore install a
description that has neither a client map nor controls, and
XkbCopyControls() then dereferences those and crashes the server.
Return -1 from ReadXkmKeyTypes() when the client map cannot be
allocated, and only report a keymap as loaded once rep.found covers
every component in fneed. Decide whether to update the actions from
rep.loaded rather than from the requested load flag, so that an
incomplete description is not handled as a successfully loaded map.
The keymap the device already had stays active when the compiled XKM
cannot be read completely.
Signed-off-by: Mikhail Dmitrichenko <m.dmitrichenko222@gmail.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2304>
(cherry picked from commit 6a4fb12019)
The ReadXkm* section readers return the number of bytes they consumed,
or -1 when they give up. That contract was spelled as int, while the
counters accumulating their results were a mix of int and unsigned, and
XkmGetCARD8/16/32() took the counter by reference as an int *.
XkmReadFile() also returns an unsigned, but that value is a bitmask of
the sections it could not read, not a byte count. Keeping byte counts in
unsigned variables right next to it makes the two easy to confuse, and
the confusion has a concrete cost: XkmReadFile() kept the readers'
results in an unsigned tmp, so the -1 that every one of the seven
readers it dispatches to can return became UINT_MAX. That passed the
tmp > 0 test below, and the section which had just failed to read was
marked as defined and cleared from the mask of sections reported as
missing.
Use ssize_t, the usual type for "a number of bytes, or -1 on failure",
for every byte count in this file: the section readers' return type, the
local counters, the counter XkmGetCARD8/16/32() take by reference, and
the return values of XkmSkipPadding() and XkmGetCountedString(). An
unsigned in this file now only ever denotes a bitmask, and a failing
section reader is no longer taken for a successful one.
ReadXkmKeyTypes() used a single tmp both for byte counts and as the
in/out element count handed to XkmInsureTypedSize(), which needs an
int *. That second use gets its own variable.
Signed-off-by: Mikhail Dmitrichenko <m.dmitrichenko222@gmail.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2304>
(cherry picked from commit bad7edcab0)
glamor_upload_boxes() allocates the tmp_bits buffer (used for 24-bit to
32-bit depth conversion) based on the destination pixmap height, but
indexes it using source coordinates (y1 - dy_dst + dy_src). When the
source is taller than the destination, the source-relative offset
exceeds the destination height, causing writes past the buffer end.
Size the buffer to account for the source coordinate mapping:
byte_stride * (pixmap->drawable.height - dy_dst + dy_src). This
ensures the buffer covers the full range of source rows that will be
accessed during the upload.
This vulnerability was discovered by:
Anonymous working with TrendAI Zero Day Initiative
ZDI-CAN-32361
CVE-2026-93522
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2341>
(cherry picked from commit ad26c26bf7)
When a window is destroyed, present_clear_window_notifies()
does not remove the notify list node from the window. The notify
may then be freed as part of the window_priv, leaving dangling
pointers in place.
When the vblank owning the notify is later torn down,
present_free_window_notify() calls xorg_list_del() which
writes through these dangling pointers (use-after-free write).
This happens when Present cross-window notifies are used: a
PresentPixmap on window A can reference window B as a notify target.
An untriggered wait_fence keeps the vblank alive so that B can be
destroyed first, creating the dangling-pointer window.
Fix this by calling the free function we have (and moving the window
reset into that function too). present_clear_window_notifies is only
called from one place anyway.
This vulnerability was discovered by:
Anonymous working with TrendAI Zero Day Initiative
ZDI-CAN-31830
CVE-2026-93515
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2341>
(cherry picked from commit 1b6955c310)
__glXDisp_RenderLarge() allocates the large command buffer based on
cmdlen (from hdr->length, the total command size embedded in the
payload), but copies dataBytes (from req->dataBytes, the payload size
of the current sub-request) into it. The existing length check only
validates that the X11 request length is consistent with dataBytes,
not that dataBytes fits within the cmdlen-sized buffer.
A malicious client can set hdr->length to a small value (e.g. 12 bytes)
while sending a large dataBytes (up to ~256KB or more with
BIG-REQUESTS), causing the memcpy to overflow the cmdlen-sized buffer.
Add a check that dataBytes <= cmdlen before the buffer allocation and
copy on the first request.
This vulnerability was discovered by:
Anonymous working with TrendAI Zero Day Initiative
ZDI-CAN-31833
CVE-2026-93517
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2341>
(cherry picked from commit 2abe4632d7)
Allow callers to arm a sigjmp_buf on a registered mapping so the
SIGBUS handler can siglongjmp instead of remapping and retrying the
faulting instruction.
Needed when the mapping contains objects that are unsafe to resume
on after a replace.
This is preparation work for the next commit where that mechanism is
used.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Assisted-by: AI
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2270>
(cherry picked from commit 7a0b3e2197)
Problem:
On a 2K (e.g. 2560x1440) display, WPS Office for Linux (Qt) shows
corrupted text and broken vertical lines on the right side of a
maximized window when the UI is updated by mouse movement (e.g.
hover/scroll refreshing labels). The same controls on the left side
are fine. The issue does not appear at 1080p, without glamor, or when
using desktop OpenGL shaders (non-GLES).
Root cause:
Xwayland GBM n-buffering CopyArea's window pixmap into the present
pixmap via glamor_copy (FBO texture blit). UVs are computed as
(offset + pixel) * (1/width, 1/height). GLES fragment shaders default
to mediump (~10-bit relative precision), so on wide pixmaps UVs near
the right edge can be off by about a pixel; with GL_NEAREST this
shows as shifted/broken glyphs and edges. Desktop OpenGL has no
default mediump precision qualifier, so the same shader path is fine.
Fix:
Force highp only on fillpos uniforms/ins/outs. Keep the global
mediump default for other fragment math.
Change-Id: If747516bdf787e0383b42e3579acfeab30a7cb1c
Signed-off-by: Kevin.Li <kevin.li@cixtech.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2315>
(cherry picked from commit 2b9ce9f6c6)
Also use `false` instead of `FALSE` in compWindowUpdate() for the bool field.
Fixes: 4a30260387 ("composite: use 'bool' instead of 'Bool' in CompClientWindowRec")
Signed-off-by: Kiyoshi Spreclerg <kiyoshi_pip@protonmail.com>
Don't have it open another one
This fixes a segfault when the render card is different from
the scanout card, and glamor uses the fast gbm import path.
If https://github.com/X11Libre/xserver/issues/2645
applies to Xmodesetting, this probably fixes it.
This is also a resource usage optimization,
since glamor doesn't allocate another gbm device
when Xmodesetting already allocates a perfectly usable one.
Signed-off-by: stefan11111 <stefan11111github@gmail.com>
