Gesture sprite traces which have the same 'fixed sprite trace
for the duration of the gesture' logic as touch sprite traces.
Both copy WindowPtrs into the trace without refcounting them.
If a device supports gestures but does not have a TouchClass,
the cleanup skipped over the gesture sprite cleanup, leaving
dangling pointers in place if a sprite trace is destroyed
during an active gesture (i.e. window is removed).
DeliverOneGestureEvent() then dereferences the stale pointer via
DeepestSpriteWin(&gi->sprite)->drawable.id, causing a use-after-free.
This vulnerability was discovered by:
4nibhal working with TrendAI Zero Day Initiative
ZDI-CAN-32753
CVE-2026-93536
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2341>
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
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2341>
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
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2341>
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>
__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>
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>
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2341>
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>
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>
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>
_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>
Drive ProcXkbGetKbdByName() with a load request through the existing
protocol test harness, once normally and once with every client map
allocation failing. The latter is what an out-of-memory condition looks
like to the XKM reader: ReadXkmKeyTypes() and ReadXkmSymbols() both give
up, so the description XkmReadFile() hands back is non-NULL but has
neither a client map nor controls. Getting there needs no malformed
xkbcomp output.
Check that the reply reports neither section as found, that it does not
claim the keymap was loaded and that the device keeps the keymap it
already had. Without the previous commit the request reports the failed
sections as read, installs the incomplete description and crashes in
XkbCopyControls().
The first test covers the other direction: a keymap that does read
completely is still installed and reported as loaded.
Signed-off-by: Mikhail Dmitrichenko <m.dmitrichenko222@gmail.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2304>
XIQueryDevice already reports the current cumulative axisVal for relative scroll valuators. Seed nonzero vertical and horizontal values and verify their FP3232 representation for native and swapped clients.
Signed-off-by: Lukáš Lipinský <18076-Mr-Tao@users.noreply.gitlab.freedesktop.org>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2292>
SwapScrollInfo converted the other multi-byte ScrollClass fields but left flags in server byte order. Swap it as well and decode the field in the swapped-client protocol test so nonzero flags exercise the wire representation.
Signed-off-by: Lukáš Lipinský <18076-Mr-Tao@users.noreply.gitlab.freedesktop.org>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2291>
SDeviceChangedEvent left ValuatorClass.value and every ScrollClass-specific multi-byte field in server byte order. Swapped clients therefore received corrupt current values and scroll metadata.
Swap those fields and extend the protocol event conversion coverage to nonzero relative valuator values and both scroll directions and flags.
Signed-off-by: Lukáš Lipinský <18076-Mr-Tao@users.noreply.gitlab.freedesktop.org>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2291>
Send a swapped ChangeDeviceControl/DEVICE_RESOLUTION with
num_valuators=255 and no valuator payload. Without the SProc length
check this overruns the request buffer; with it the server returns
BadLength.
Co-authored-by: Cursor <cursoragent@cursor.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2285>
We make two glyphsets, GS1 and GS2, both with the same format depth.
GS1 contains any glyph different from the others, let's call it U
(unique). GS2 contains two glyphs with the same content, or at least
sha1 hash. Let's call them A and B.
We first register GS1 and GS2. GS1 has no problems, but before the
fix, registering GS2 breaks accounting in `globalGlyphs`. Since there
is no check for duplicate glyphs within a single set, we make two
`GlyphNew` entries for A and B. Now in the loop at the end, we go over
each entry and call `AddGlyph` and `FreeGlyph`:
1. AddGlyph(GS2, A, idA) inserts A into `globalGlyphs`
2. FreeGlyph(A) drops A's refcnt by one, but as it's being held in
`globalGlyphs` it's kept alive.
3. AddGlyph(GS2, B, idB) finds A in `globalGlyphs` and reuses it
instead of inserting B
4. FreeGlyph(B) drops B's refcnt by one (to zero), and B is freed.
Before the fix, the lookup in `globalGlyphs` finds A's entry, and
since it isn't a DeletedGlyph, it erroneously removes the
`gr->glyph` pointing to `A` and decrements `tableEntries`. This
results in `tableEntries` being off-by-one as `A` is still alive.
Now, we free the glyphsets in a particular order. Freeing GS1 results
in calling FreeGlyph(U), which will decrement U's refcnt to zero, and
free U. This clears out the entry in `globalGlyphs` for U and
decrements `tableEntries`, which due to the earlier error is now zero.
When `FreeGlyphSet` sees this, it clears the `globalGlyphs` for that
format depth. Now freeing A or GS2 (which transitively frees A) will
try to check the `globalGlyphs` at that format depth, but because it
was cleared out this crashes.
The fix here is to change FreeGlyph to only free a glyph from
`globalGlyphs` that is exactly the glyph being freed, so that
FreeGlyph(B) doesn't touch `globalGlyphs` at all. This keeps a proper
count in `tableEntries` and prevents `globalGlyphs[fdepth]` from being
freed before A is freed.
Closes: #1881
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2264>
At this point, allowing X Font Server connections just introduces us to
possible security issues since the code effectively trusts any font
server and few checks are in place.
Since font servers also haven't been used for ages, let's disable
them by default. Use-cases that require them will have to pass
+fontserverconnections on the commandline and/or set the corresponding
ServerFlags option.
The tests are a bit hacky: Debian builds libXfont2 with --disable-fc so
we need to cater for the case where the X server enables fontserver support
but libXfont then blocks it and we still need to treat this as success.
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2263>
The X11 core protocol error code constants (BadRequest, BadValue,
BadWindow, etc.) belong with the other protocol definitions in
proto/x11.py rather than in the client connection module.
Move the canonical definitions to proto/x11.py and re-export them from
xclient.py for backward compatibility. Update all test files to import
from proto.x11 instead.
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2263>
glamor_font_get() computes the atlas slot size from the font's declared
maxbounds, but copies each glyph's bitmap using the per-glyph metrics
(GLYPHHEIGHTPIXELS/GLYPHWIDTHBYTES macros). When a malicious PCF font
has per-glyph metrics exceeding maxbounds, the memcpy writes past the
heap-allocated atlas buffer. Negative per-glyph metrics are even worse:
the loop counter wraps to ~4 billion iterations (via unsigned cast) or
memcpy's size parameter wraps to SIZE_MAX.
The PCF parser in libXfont2 does not recompute maxbounds from per-glyph
data (only the BDF parser does), so the file's declared maxbounds values
are trusted as-is.
Reject fonts where any per-glyph metric is negative or exceeds the
atlas slot size, falling back to software rendering which uses per-glyph
metrics directly without an atlas.
This vulnerability was discovered by:
Anonymous working with Trend Micro Zero Day Initiative
CVE-2026-55999/ZDI-CAN-30498
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2250>
GLYPHWIDTHPIXELS and GLYPHHEIGHTPIXELS compute glyph dimensions from
signed INT16 fields. A crafted PCF font can produce negative results
(e.g. rightSideBearing < leftSideBearing).
All callees have a while (height--) loop which will end up in OOB writes
for negative height values.
In the case of a negative height, some callees cast to size_t or end up
with negative strides.
The same pattern exists in fbPoloyGlyphBit, miPolyGlyphBlt and
glamor_poly_glyph_blt_gl, so let's fix all of them in one go.
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2250>
oldTag in CommonMakeCurrent() is a pointer to cl->contextTags[...].
CommonMakeCurrent() may realloc(cl->contextTags) and thus move the
memory, leaving oldTag as dangling pointer.
If we then GlxFreeContextTag(oldTag) we end up writing into freed
memory.
Fix this by freeing oldTag before CommonMakeNewCurrent().
This vulnerability was discovered by:
Anonymous working with Trend Micro Zero Day Initiative
CVE-2026-56000/ZDI-CAN-30561
Fixes: 4781f2a5a8 ("GLX: Free the tag of the old context later")
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2250>
On Solaris, to get information about the process on the other side of
a socket, we use the getpeerucred() system call instead of the
SO_PEERCRED socket option.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2241>
Add TestScreenSaverFreeAttr which exercises the ScreenSaverFreeAttr
code path by setting attributes, activating the screen saver, then
closing the client connection (triggering resource cleanup).
While ScreenSaverFreeAttr currently does not dereference pPriv after
CheckScreenPrivate, this test verifies the code path is safe and
would catch regressions if future code changes introduced a stale
pointer dereference (same pattern as ZDI-CAN-30168).
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2228>
Add ListFonts, SetFontPath, and GetFontPath protocol builders to
proto/x11.py and a regression test that reproduces the
doListFontsAndAliases stack buffer overflow.
The test creates a temporary font directory with a fonts.alias file
containing an alias whose target name is 400 bytes -- exceeding the
old XLFDMAXFONTNAMELEN of 256 but under libXfont2's MAXFONTNAMELEN of
1024. It prepends this directory to the font path via SetFontPath, then
sends ListFonts matching the alias name. Without the fix, the server
would copy the oversized resolved name into a 256-byte stack buffer,
causing a stack buffer overflow.
ZDI-CAN-30136
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2228>
Add a regression test that reproduces the mapWidths stack buffer overflow
in CheckKeyTypes.
The test sends two XkbSetMap requests: first with firstType=0, nTypes=255,
ResizeTypes to expand the type table to 255 entries, then with
firstType=255, nTypes=10, ResizeTypes. The second request passes the
firstType > num_types check (255 > 255 is false) and computes
nMaps = 255 + 10 = 265. Without the fix, the loop would write
mapWidths[255..264], overflowing 9 bytes past the 256-element stack
buffer into adjacent stack variables.
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2228>
Add a regression test that reproduces the XKB num_levels stack overflow.
The test sends an XkbSetMap request with XkbSetMapResizeTypes that includes
a non-canonical key type with numLevels=255, exceeding XkbMaxShiftLevel
(63). Without the fix, this type would be accepted and stored in the
server's type table. A subsequent ChangeKeyboardMapping would trigger
XkbUpdateKeyTypesFromCore -> XkbKeyTypesForCoreSymbols, where the
oversized num_levels is used as groupsWidth, causing indices into the
tsyms[252] stack buffer to reach up to 1019 and overflow.
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2228>
Add screensaver protocol builders for SetAttributes, UnsetAttributes, and
ForceScreenSaver, then add a regression test that reproduces the
CreateSaverWindow use-after-free.
The test sequence:
1. SetAttributes(root, 100x100, mask=0) - creates screen private with attr
2. ForceScreenSaver(Active) - creates the saver window
3. UnsetAttributes(root) - clears pPriv->attr to NULL
4. ForceScreenSaver(Active) - re-enters CreateSaverWindow
Without the fix, step 4 triggers CheckScreenPrivate which finds all fields
empty (attr=NULL, events=NULL, hasWindow=FALSE, installedMap=None), frees
pPriv, and sets the screen private to NULL. The function then dereferences
the freed pPriv->attr pointer, causing a use-after-free.
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2228>
Add a regression test that reproduces the SyncChangeCounter use-after-free.
The test creates a counter (value=0) and issues SyncAwait with two
conditions on the same counter, both waiting for value >= 1. A second
client then calls SetCounter to set the value to 100. SyncChangeCounter
iterates triggers; the first fires and FreeAwait frees all sibling trigger
list nodes via SyncDeleteTriggerFromSyncObject. Without the fix, the saved
pnext pointer would dangle, and the next iteration would dereference freed
heap memory.
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2228>
Add SYNC extension protocol builders (proto/sync.py) and a regression test
that reproduces the miSyncDestroyFence and FreeCounter use-after-free.
The first test creates a fence and issues AwaitFence with the same fence ID
listed twice, creating two trigger list nodes pointing into one
SyncAwaitUnion. A second client then destroys the fence. Without the fix,
miSyncDestroyFence would invoke CounterDestroyed before saving the next
pointer, and the first callback would free the SyncAwaitUnion while the
second trigger list node still referenced it.
The second test creates a counter (value=0) and issues SyncAwait with two
conditions on the same counter, both waiting for value >= 1. Since the
counter is 0, Client A blocks. A second client then destroys the counter.
Without the fix, FreeCounter would invoke CounterDestroyed before saving
the next pointer in the trigger list, and the first callback would free
the SyncAwaitUnion while the second trigger node still referenced it.
ZDI-CAN-30163 (FreeCounter)
ZDI-CAN-30159 (miSyncDestroyFence)
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2228>
Add GLX extension protocol builders (proto/glx.py) and a regression test
that reproduces the reversed length check in ChangeDrawableAttributes.
The test creates a GLX context on the root visual, binds it with
MakeCurrent (which auto-creates a GLXDrawable), then sends a
ChangeDrawableAttributes request with length=3 (12 bytes) but
numAttribs=2100. Without the fix, the reversed comparison operator (<
instead of >) would let this undersized request pass validation, and
DoChangeDrawableAttributes would iterate 2100 attribute pairs, reading
far past the 12-byte request buffer.
Assisted-by: Claude:claude-opus-4-6
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2228>
xclient.send_request() should just take a Request object and handle
to_bytes with the right byte order. This avoids typos/copy-paste errors
in tests when the byte order changes between tests.
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2216>
This test was missing SetClientVersion(2) so the reply was a the old 0.x
protocol (and the 36 byte GetModeLine reply). Update so it runs for both
versions now.
Fixes: acbc46e708 ("pyxtest: add tests for the byteswapping patches")
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2213>
