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>
Instead of having glamor_egl create the gbm device, let the ddx create
it and pass it to glamor.
This allows for saving some resources and for fixing a
bug on amd (if it still happens)
Signed-off-by: stefan11111 <stefan11111github@gmail.com>
Instead of hard typecasts on event proc assignment, better accept the
expected parameter types and do the typecast inside the functions.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead of hard typecasts on event proc assignment, better accept the
expected parameter types and do the typecast inside the functions.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Each test starts its own X server via -displayfd, and pytest-xdist runs
several workers (meson several suites) in parallel. Servers scanning for a
free display number at the same time can both end up claiming the same one:
the losing test's client then connects to the winner's server, and when the
winner is torn down at the end of its own test the loser's connection dies
mid-test. It surfaces as an opaque
BrokenPipeError: [Errno 32] Broken pipe
test/pyxtest/xclient.py:270: in send_request / self.sock.sendall(data)
in an unrelated test, which looks like a flake and hides the cause.
Hold a cross-process lock for the short display-allocation window (Popen
plus reading the display number). Once a server has announced its display
it owns the socket and the lock file, so later servers skip that number and
that window is the only place the race can happen.
As a safety net, record the server PID that owns the socket (SO_PEERCRED)
and fail the xclient fixture with a clear message when it is not the server
the fixture started, instead of leaving a confusing BrokenPipeError.
Measured with a --buildtype=debug build and 4 pytest-xdist workers, 40
parallel pytest sessions of test_xi.py: before, 7 sessions failed with
"connected to PID X instead of the test server" and 5 with
BrokenPipeError; after, 0 of 40, plus 0 errors over 8 full test/pyxtest
runs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The xvfb / xehypr / xehypr-glamor display-info tests each start their own X
server (Xvfb, or Xephyr nested inside Xvfb) via simple-xinit -displayfd. When
several of them start at the same instant, the servers race on the same display
numbers and the losing client ends up with a display it cannot open, failing the
lane intermittently:
_XSERVTransSocketUNIXCreateListener: /tmp/.X11-unix/X0 already in use
_XSERVTransMakeAllCOTSServerListeners: server already running
xdpyinfo: unable to open display ":1".
This reproduces on master (run 38774811861) as well as on PRs, hitting a
different display-info subtest each time, so it is a harness race and not a
regression in the code under test. Mark these tests is_parallel:false so the
display allocation cannot collide. The tests are short, so the lost parallelism
is negligible.
Test-harness only, no production code change.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead of hard typecasts on event proc assignment, better accept the
expected parameter types and do the typecast inside the functions.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead of hard typecasts on event proc assignment, better accept the
expected parameter types and do the typecast inside the functions.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead of hard typecasts on event proc assignment, better accept the
expected parameter types and do the typecast inside the functions.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead of hard typecasts on event proc assignment, better accept the
expected parameter types and do the typecast inside the functions.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead of hard typecasts on event proc assignment, better accept the
expected parameter types and do the typecast inside the functions.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead of hard typecasts on event proc assignment, better accept the
expected parameter types and do the typecast inside the functions.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The global static swapEvent/swapEventLen buffer in WriteEventsToClient()
was a persistent allocation that grew on demand. Replace with a
per-call calloc/free to avoid holding memory indefinitely and to
eliminate a static state that is not thread-safe.
The previous logic grew the buffer via realloc() and kept it for the
life of the process. The new logic allocates exactly eventlength bytes
for each swapped WriteEventsToClient() call, uses it for all events
in that call, and frees it before returning.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Check CursorConfinedTo and CursorWarpedTo function pointers directly without
dereferencing them in 'if' conditions in events and xiwarppointer
Signed-off-by: Herman Semenoff <GermanAizek@yandex.ru>
The purge script was deleting workflow runs for PRs from forks because it
only checked branch existence in the main repo (X11Libre/xserver). Fork PR
branches don't exist there, so their runs were deleted immediately.
Fix: fetch the 'pull_requests' field from the workflow run API and skip
deletion if any associated PR is still open. Also fetch head_repository
for logging.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's just an ancient relic from previous century, that's ever been helpful
in a few corner cases - and can be easily replaced by -config / -configdir
cmdline options.
OTOH, it's a potential security risk for Xservers running with suid root
(eg. if it somehow fails to detect/switch to the restricted mode)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The X11 protocol requires each window to be destroyed in turn.
Previously, DestroySubwindows unmapped all child windows first.
This sent all UnmapNotify events before any DestroyNotify events.
Removing the UnmapSubwindows call lets each child window be unmapped
and destroyed individually. This restores correct event ordering.
Each child now runs its own ValidateTree pass instead of sharing one.
This diverges from xorg/main, which still carries the UnmapSubwindows
shortcut and its XXX comment.
Signed-off-by: Mason Green <mason@greenm01.net>
- Build jobs (ubuntu-install-pkg): use actions/cache/restore@v5 with fail-on-cache-miss=false
→ optional warm cache, no failure on miss, no write-back (no locking conflicts)
- New action ubuntu-save-apt-cache: actions/cache/save@v5 with global key
→ only this action writes the cache
- New workflow ubuntu-apt-cache.yml: daily 02:00 UTC + master push
→ proactively populates global apt cache
- Removed ubuntu-fetch-pkg job and all needs: ubuntu-fetch-pkg dependencies
→ build jobs run independently, no chain delay causing cache TTL expiry
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
