Replace shadow-type standalone xaverius registry test with meson-built tests using real XAverius headers in test/tests, covering identity comparison, ordering keys, module-role ownership hooks, and registration/binding lifecycle paths.
- New test/xaverius-registry-test.c covering:
* ModuleRoleDescriptor struct_size/abi_version validation
* Identity comparison (PCI, DRM, UUID, cross-class)
* Canonical ordering key generation and comparator
* Descriptor size validation
- test/meson.build: Add xaverius-registry-test executable (conditionally
built when xaverius enabled; test registration currently disabled due
to meson link ordering with xorg_link).
- Deep copy all four nested operation tables (buffer_memory,
shader_pipeline, commands, synchronization) in xaverius_binding_alloc()
with atomic rollback on allocation failure.
- Add caller_refcount to XaveriusPhysicalDevice for proper
XaveriusPhysicalDeviceRelease() semantics. Exact replay increments
refcount; Release decrements it.
- Fix XaveriusPhysicalDeviceDIXDestroy(): no longer modifies
XaveriusPhysicalDeviceType (resource type ID). Only acknowledges
resource destruction.
- Implement canonical ordering key per spec: identity_class:pci_or_drm:
device_uuid:driver_uuid:owner_key with bytewise lexicographic comparator.
- Remove tautological sizeof() checks in registration; use field-by-field
xaverius_identity_equal() for identity comparison.
- Fix XaveriusRegistryFini() to properly free deep-copied operation tables
via new xaverius_binding_free() helper.
- Fix XaveriusRegistryRemoveDeviceBackendBinding() to use binding_free.
- ModuleRoleCreate() now stores module_lease from descriptor.
- Add internal validation functions: xaverius_module_role_descriptor_valid(),
xaverius_identity_equal(), xaverius_identity_has_pci().
- Remove duplicate typedef of XaveriusPhysicalDevice from xaverius_intern.h
(forward declaration only; full typedef remains in xaverius_priv.h).
Fixes OpenBSD clang -Wtypedef-redefinition error.
- Update ModuleRoleDescriptor and internal ModuleRole struct to use
XaveriusModuleRole* instead of void* for retain/release/quiesce callbacks.
quiesce_module_role now returns XaveriusModuleQuiescenceResult per ABI v1.
- Add ModuleRoleAdmission and ModuleRoleQuiesceState enums to intern.h.
- Fix static assertion macro in xaverius_proto.h to properly expand __LINE__
via XAVERIUS_STATIC_ASSERT_4 helper (was already present but confirmed).
The test/meson.build referenced xorg_inc variable which is only defined when build_xorg=true.
This caused meson configuration to fail when building with -Dxorg=false -Dxaverius=true.
Fixed by making xorg_inc conditional on build_xorg option in test/meson.build.
The xaverius-registry-test target was already removed in a previous commit.
Fixes: -Dxorg=false -Dxaverius=true build configuration
Fix the C99 fallback for XAVERIUS_STATIC_ASSERT by adding a third-level
macro to force expansion of __LINE__ before token concatenation.
The previous implementation used __LINE__ directly in the macro argument,
which doesn't expand before token concatenation, causing all static
assertions to generate the same identifier 'xav_static_assert___LINE__'
instead of unique line numbers.
Fixed by adding an intermediate macro XAVERIUS_STATIC_ASSERT_3 that
forces __LINE__ expansion before passing to the helper.
Build: green (-Werror)
Tests: 153/154 passing (1 pre-existing failure in signal_logging_test unrelated)
Signed-off-by: Defiant <defiant@x11libre.org>
* add screen private structures for xaverius
* DDX drivers can attach themselves into Xaverius stack and install
their xaverius operation callbacks via XaveriusScreenInit()
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This only registers the extension, but nothing else than a trivial stub.
Enable building it via passing -Dxaverius=true to meson.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
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>
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>
