Timo Aaltonen pushed to branch upstream-unstable at X Strike Force / xserver / xorg-server
Commits: 61cc2b45 by Jeremy Huddleston Sequoia at 2026-07-15T09:39:28-07:00 xquartz: Activate the app via xp_window_activate() in -set_front_process: -[NSApplication activateIgnoringOtherApps:] is no longer supported under the macOS cooperative activation model, so use the new xp_window_activate() API instead. Signed-off-by: Jeremy Huddleston Sequoia <[email protected]> (cherry picked from commit 1133421bbd4a0b4064ac0e9565bde8c7034277f1) - - - - - 4430eab7 by Alan Coopersmith at 2026-07-18T16:43:21+00:00 gitlab CI: add workflow rules Needed due to the gitlab config changes described in: https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/438 Signed-off-by: Alan Coopersmith <[email protected]> (cherry picked from commit 445834826d4590d4d6f1f9f50c78df170835f02a) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2261> - - - - - 05c4d577 by Michel Dänzer at 2026-07-18T16:43:21+00:00 ci: Prevent duplicate pipelines for MRs Do not create a pipeline for $CI_PIPELINE_SOURCE == 'push' if $CI_OPEN_MERGE_REQUESTS is set, which means there are open MRs using the branch as the source. (cherry picked from commit d757aabd50c27e4693721c0bd35c046ddfe7e22e) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2261> - - - - - 85661fec by Martin von Gagern at 2026-07-18T10:21:42-07:00 modesetting: Check for NULL mode_output before printing warning message Fixes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1816 Signed-off-by: Martin von Gagern <[email protected]> (cherry picked from commit 0d39d7a8f31cf2519b7743ea4964eecc4d0aead9) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2260> - - - - - 24688ccd by Jeremy Huddleston Sequoia at 2026-08-16T13:42:13-07:00 xquartz/GL: Log failures on the indirect GLX make-current path The indirect GLX make-current path failed silently: an unsuccessful surface creation or context attach surfaced only as a generic GLXBadContext to the client, with nothing in the server log to indicate which Xplugin call rejected the request. Add error logging on each failure branch of the make-current, surface creation, and surface configuration code so the offending call and its error code are visible. Signed-off-by: Jeremy Huddleston Sequoia <[email protected]> (cherry picked from commit cf0bdc8d6181129f76fed8667f635eadf5070250) - - - - - 368ff1d5 by Jeremy Huddleston Sequoia at 2026-08-16T13:42:14-07:00 fb: Don't widen the planemask over padding bits when ROOTLESS_SAFEALPHA is set Wide LineDoubleDash lines drew black on screen under XQuartz while the server's own XGetImage readback showed the correct pixels, because at depth 24 that readback ignores alpha. Opaque text and dashed arcs take the same path. fbValidateGC widens a planemask that covers the drawable's depth to cover its full bits per pixel, so the blit and fill paths can take their all-ones shortcuts. On a rootless server that also writes the alpha channel of the window's premultiplied surface, which CoreGraphics then composites as black. Rootless keeps that alpha opaque by clearing the bits from the planemask, but only its own ValidateGC does so, and mi revalidates the GC in the middle of a drawing operation to swap the foreground for the background pixel. By then the damage layer has unwrapped the rootless funcs down to fb, so the reassertion never happens and the rest of the operation lands with a zero alpha channel. Fixes: https://github.com/XQuartz/XQuartz/issues/230 Signed-off-by: Jeremy Huddleston Sequoia <[email protected]> (cherry picked from commit 1e64827614ae304e169a34561ea7c211fb98fc60) - - - - - 8d604fa1 by Octavia Togami at 2026-08-26T10:02:23+02:00 Fix use-after-free caused by duplicate glyphs in one glyphset 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 See-also: https://gitlab.freedesktop.org/xorg/xserver/-/work_items/1914 (cherry picked from commit 67e7343b588af3852418ea6a0316a326f5c947d2) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2294> - - - - - 431125a2 by Gary T. Giesen at 2026-08-31T10:14:58-04:00 xfree86: set GPU screen FB/DGA defaults on runtime hotplug When a platform GPU device is added at runtime, xf86platformAddDevice calls AddGPUScreen without first assigning the EnableDisableFBAccess and SetDGAMode function-pointer defaults. The boot path in xf86Init.c sets both of these for every GPU screen before it calls AddGPUScreen, so a screen added by hotplug is left with SetDGAMode == NULL. modesetting's ScreenInit reaches xf86CrtcScreenInit, which wraps DGACloseScreen onto the screen regardless of how the screen was created. When the device is later removed, xf86platformRemoveDevice tears the GPU screen down and DGACloseScreen calls pScrn->SetDGAMode(pScrn, 0, NULL). On a hotplug-added screen that pointer is NULL, so the call faults and takes down the server with a SIGSEGV. This is not DisplayLink-specific: any modesetting platform GPU screen added at runtime and later removed hits it. DisplayLink/evdi just makes it easy to reproduce, because the evdi platform device is added and reconfigured at runtime. Mirror the boot path by assigning the same defaults in xf86platformAddDevice immediately before the AddGPUScreen call. Closes: #1904 Signed-off-by: Gary T. Giesen <[email protected]> (cherry picked from commit dbcd36b38faac64f23006825d6441d9ecec7310a) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2302> - - - - - 640a9671 by Gary T. Giesen at 2026-08-31T10:14:58-04:00 config/udev: guard against NULL subsystem in fallback bus id config_udev_get_fallback_bus_id() passes the result of udev_device_get_subsystem() straight into strcmp(). That accessor can return NULL when the device has no subsystem, so strcmp(NULL, "pci") dereferences a NULL pointer and the server crashes with a SIGSEGV. The path is reached for any DRM device with no udev ID_PATH property, where config_udev_odev_setup_attribs() falls back to this function. DisplayLink/evdi virtual cards have no ID_PATH; a udev remove of such a card during teardown can present a parent whose subsystem is already gone (reported NULL), and the unchecked strcmp faults. The same NULL-subsystem-into-strcmp class was fixed for the four sibling callers in this file by commit 429ee86a; config_udev_get_fallback_bus_id() was added later (commit 2f53d1cf) without the guard. The preceding parent==NULL case is already guarded here; extend the same defensiveness to the subsystem lookup. Related to: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1905 Signed-off-by: Gary T. Giesen <[email protected]> (cherry picked from commit 9babe7e7f687b0342c8ab726d01a658d590d7c54) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2302> - - - - - 62758ed3 by NetSysFire at 2026-10-03T17:37:42-07:00 xorg.conf.man: Fix escape sequence typo (cherry picked from commit 128a4827c910ded230e04aec632e7c618f4d84f6) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2336> - - - - - 05ddf2f8 by dongshengyuan at 2026-10-03T17:40:20-07:00 enhance: popen-fdopen-error-handling If fdopen() fails, close the unused pipe fd, free the pid list node, and restore the smart scheduler signal before returning NULL. Previously the fd would leak and the node would be added to pidlist with a NULL fp. Signed-off-by: dongshengyuan <[email protected]> (cherry picked from commit 7023ecca450be10ef1949389e6a15f416bef2c8b) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2336> - - - - - a8aa186d by Alan Coopersmith at 2026-10-03T17:45:54-07:00 xkb: Fix -Wcalloc-transposed-args warning in _XkbCopyGeom() Reported by gcc 16.1: xkb/xkbUtils.c:1440:39: warning: ‘calloc’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Wcalloc-transposed-args] 1440 | dst->geom = calloc(sizeof(XkbGeometryRec), 1); | ^~~~~~~~~~~~~~ Signed-off-by: Alan Coopersmith <[email protected]> (cherry picked from commit de30aa836538304b2f730d69c845d83a96ac1a16) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2336> - - - - - 6710bc2f by Alan Coopersmith at 2026-10-03T17:46:38-07:00 xf86: prevent passing NULL pointer as strcpy destination Reported by gcc 16.1: hw/xfree86/common/xf86Configure.c:463:9: warning: use of NULL where non-null expected [CWE-476] [-Wanalyzer-null-argument] 463 | strcpy(ptr->mon_modelname, (char *) (det_mon->section.name)); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ‘handle_detailed_input’: events 1-5 458 | switch (det_mon->type) { | ^~~~~~ | | | (1) following ‘case 252:’ branch... ─>─┐ | │ | │ |┌───────────────────────────────────────────┘ 459 |│ case DS_NAME: |│ ~~~~ |│ | |└───>(2) ...to here 460 | ptr->mon_modelname = realloc(ptr->mon_modelname, | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | | | | | (3) when ‘realloc’ fails | (4) using NULL here 461 | strlen((char *) (det_mon->section.name)) + | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 462 | 1); | ~~ 463 | strcpy(ptr->mon_modelname, (char *) (det_mon->section.name)); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | | | (5) ⚠ argument 1 (‘realloc(*(struct <anonymous> *)data.mon_modelname, strlen(&*det_mon.section.name) + 1)’) NULL where non-null expected note: argument 1 of ‘strcpy’ must be non-null Signed-off-by: Alan Coopersmith <[email protected]> (cherry picked from commit 38ab3fd3debed4e49896b34ac7f3e03fe590ee79) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2336> - - - - - 8be31cfe by Alan Coopersmith at 2026-10-03T17:47:27-07:00 xf86: prevent passing NULL pointer as strcat() destination Reported by gcc 16.1: hw/xfree86/parser/Files.c:119:17: warning: use of NULL where non-null expected [CWE-476] [-Wanalyzer-null-argument] 119 | strcat(ptr->file_fontpath, ","); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ...... 117 | ptr->file_fontpath = realloc(ptr->file_fontpath, i); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | | | | | (9) when ‘realloc’ fails | (10) using NULL here 118 | if (j) | ~ | | | (11) following ‘true’ branch (when ‘j != 0’)... ─>─┐ | │ | │ |┌──────────────────────────────────────────────────────────────────┘ 119 |│ strcat(ptr->file_fontpath, ","); |│ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |│ | |└───────────────>(12) ...to here | (13) ⚠ argument 1 (‘realloc(*ptr.file_fontpath, (long unsigned int)i)’) NULL where non-null expected <built-in>: note: argument 1 of ‘__builtin_strlen’ must be non-null ...... | │ |┌──────────────────────────────────────────────────────────────────┘ 121 |│ strcat(ptr->file_fontpath, str); |│ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |│ | | |│ | (10) using NULL here |└───────────>(9) ...to here | (11) ⚠ argument 1 (‘*ptr.file_fontpath’) NULL where non-null expected note: argument 1 of ‘strcat’ must be non-null hw/xfree86/parser/Files.c:144:17: warning: use of NULL where non-null expected [CWE-476] [-Wanalyzer-null-argument] 144 | strcat(ptr->file_modulepath, ","); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ...... 142 | ptr->file_modulepath = realloc(ptr->file_modulepath, k); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | | | | | (9) when ‘realloc’ fails | (10) using NULL here 143 | if (l) | ~ | | | (11) following ‘true’ branch (when ‘l != 0’)... ─>─┐ | │ | │ |┌──────────────────────────────────────────────────────────────────┘ 144 |│ strcat(ptr->file_modulepath, ","); |│ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |│ | |└───────────────>(12) ...to here | (13) ⚠ argument 1 (‘realloc(*ptr.file_modulepath, (long unsigned int)k)’) NULL where non-null expected <built-in>: note: argument 1 of ‘__builtin_strlen’ must be non-null ...... | │ |┌──────────────────────────────────────────────────────────────────┘ 146 |│ strcat(ptr->file_modulepath, str); |│ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |│ | | |│ | (10) using NULL here |└───────────>(9) ...to here | (11) ⚠ argument 1 (‘*ptr.file_modulepath’) NULL where non-null expected note: argument 1 of ‘strcat’ must be non-null Also clears two -Wanalyzer-malloc-leak warnings for leaking the old pointer when realloc() failed, now that realloc() cannot fail. Signed-off-by: Alan Coopersmith <[email protected]> (cherry picked from commit 43710f61faf9924419f77896038e49107a676b2f) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2336> - - - - - 9ac6dd95 by Alan Coopersmith at 2026-10-03T17:48:05-07:00 xf86: silence -Wanalyzer-possible-null-dereference warning in parser Reported by gcc 16.1: hw/xfree86/parser/Files.c:131:41: warning: dereference of possibly-NULL ‘*ptr.file_modulepath’ [CWE-690] [-Wanalyzer-possible-null-dereference] 131 | ptr->file_modulepath[0] = '\0'; | ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~ [...] 130 |│ ptr->file_modulepath = malloc(1); |│ ~~~ ~~~~~~~~~ |│ | | |└───────────────>(8) ...to here (9) this call could return NULL 131 | ptr->file_modulepath[0] = '\0'; | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | | | (10) ⚠ ‘malloc(1)’ could be NULL: unchecked value from (9) Signed-off-by: Alan Coopersmith <[email protected]> (cherry picked from commit 61668cf321c0b222cbe01af3c7f38063b2589e8b) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2336> - - - - - 9f933f5e by Alan Coopersmith at 2026-10-03T17:48:23-07:00 test: silence -Wanalyzer-null-argument warnings in strndup tests Catch malloc failures before calling strcmp() with them. Signed-off-by: Alan Coopersmith <[email protected]> (cherry picked from commit e7644f938afa7e9748345e65fb2d7be745c59635) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2336> - - - - - 04a8af36 by Alan Coopersmith at 2026-10-03T17:48:53-07:00 exa: silence -Wold-style-declaration warning from gcc 16 exa/exa_accel.c:239:1: warning: ‘inline’ is not at beginning of declaration [-Wold-style-declaration] 239 | static Bool inline | ^~~~~~ Signed-off-by: Alan Coopersmith <[email protected]> (cherry picked from commit 3d22aaf07f4d6397885a44f33bca69a0c5c47337) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2336> - - - - - 4a55d1dd by Alan Coopersmith at 2026-10-03T17:49:23-07:00 xf86: handle malloc failure in DoSubstitution() Reported by gcc 16.1: hw/xfree86/parser/scan.c:562:65: warning: use of possibly-NULL ‘result’ where non-null expected [CWE-690] [-Wanalyzer-possible-null-argument] 562 | strcpy(result + l, s); \ | ^~~~~~~~~~~~~~~~~~~~ hw/xfree86/parser/scan.c:595:21: note: in expansion of macro ‘APPEND_STR’ 595 | APPEND_STR(cmdline); | ^~~~~~~~~~ Signed-off-by: Alan Coopersmith <[email protected]> (cherry picked from commit c26e2081cba3fdf79bd6fe6e37f042d26b2a930e) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2336> - - - - - abe65477 by Alan Coopersmith at 2026-10-03T17:49:44-07:00 Handle -Wimplicit-fallthrough warnings from gcc 16.1 Gets rid of 36 -Wimplicit-fallthrough warnings Signed-off-by: Alan Coopersmith <[email protected]> (cherry picked from commit 989e42c1d46a241bd54475d2e062dceed314a97a) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2336> - - - - - 9b6673ec by Alan Coopersmith at 2026-10-03T17:53:22-07:00 meson: only install dri3.h if building dri3 support Reported-by: Thomas Klausner <[email protected]> Signed-off-by: Alan Coopersmith <[email protected]> (cherry picked from commit dc8e08825aba7e387e81773647b2257f2189c6f8) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2336> - - - - - 608f870d by Lukáš Lipinský at 2026-10-03T17:54:12-07:00 Xi: byte-swap DeviceChanged valuator and scroll data 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ý <[email protected]> (cherry picked from commit cf91b97d6c7c3ec24a4b161484921f5d4ca5a6de) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2336> - - - - - 5ca3b07f by Lukáš Lipinský at 2026-10-03T17:54:26-07:00 Xi: byte-swap XIQueryDevice ScrollClass flags 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ý <[email protected]> (cherry picked from commit 8033c4d93ea140025fea5e7294bb4e92c0cd6af5) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2336> - - - - - d3d92167 by Jeremy Huddleston Sequoia at 2026-10-03T17:56:05-07:00 RegionValidate: Fix double free of badreg->data on the error path RegionValidate() copies *badreg into ri[0].reg, so ri[0].reg.data aliases badreg->data. A later RECTALLOC_BAIL() can realloc() that block and move it, updating ri[0].reg.data but not badreg->data. On the bail path, freeing ri[0].reg.data and then calling RegionBreak(badreg) frees badreg->data a second time, which by then is a stale pointer into memory already freed or reallocated to something else. Signed-off-by: Jeremy Huddleston Sequoia <[email protected]> (cherry picked from commit 4ef1b4cd2690c6d8e4b029b02bf707cb04d0da24) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2336> - - - - - 1bef8d9f by pkubaj at 2026-10-03T18:21:02-07:00 meson: Fix build on FreeBSD/powerpc* Current error: ld: error: undefined symbol: xf86EnableIO >>> referenced by xf86Configure.c >>> libxorg_common.a.p/xf86Configure.c.o:(DoConfigure) in archive >>> hw/xfree86/common/libxorg_common.a >>> referenced by xf86Events.c >>> libxorg_common.a.p/xf86Events.c.o:(xf86VTEnter) in archive >>> hw/xfree86/common/libxorg_common.a >>> referenced by xf86Init.c >>> libxorg_common.a.p/xf86Init.c.o:(InitOutput) in archive >>> hw/xfree86/common/libxorg_common.a >>> referenced 1 more times (cherry picked from commit 8c54d590cbcad5579548d53499ce0bf501bd56bb) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2336> - - - - - 5981d49e by Alan Coopersmith at 2026-10-03T18:21:06-07:00 meson: check cpu_family() instead of cpu() meson documents the values returned by cpu_family() as stable, but not those returned by cpu(): https://mesonbuild.com/Reference-tables.html#cpu-families https://mesonbuild.com/Reference-manual_builtin_host_machine.html We already use cpu_family() in most instances, but had missed a few. Signed-off-by: Alan Coopersmith <[email protected]> (cherry picked from commit 71c7824e806b1f216a2a90e12d3d3b7de9d1a7a9) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2336> - - - - - 0fb16f3d by Jeremy Huddleston Sequoia at 2026-10-03T18:21:06-07:00 damage: Unlink a damage from the list it was actually inserted on DamageRegister() chooses which list a damage is linked onto via getDrawableDamageRef(), but DamageUnregister() and damageSetWindowPixmap() re-derived that list at removal time. For a window the answer depends on the window pixmap, which changes while the damage is registered (Composite redirection, rootless drawing and Present flips all swap it), so the removal could consult a different list than the one the damage was inserted onto. It then silently found nothing -- DAMAGE_VALIDATE_ENABLE is off, so the diagnostic is compiled out -- and left an unregistered, often freed, damage linked where damageRegionAppend() would later dereference its NULL pDrawable and crash. Record the list head when linking a damage and always unlink from that, which also drops a use-after-free read of the old window pixmap in damageSetWindowPixmap(): rootless frees its scratch pixmap before restoring the pre-drawing window pixmaps, so the pixmap consulted there had already been destroyed. Fixes: https://github.com/XQuartz/XQuartz/issues/406 Signed-off-by: Jeremy Huddleston Sequoia <[email protected]> (cherry picked from commit da72833185481481052972f031262e94976131ef) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2336> - - - - - 0cfe0657 by Jeremy Huddleston Sequoia at 2026-10-03T18:21:06-07:00 xkb: Guard XkbAdjustGroup() against a keymap with no groups When every key in a keymap has zero groups, ctrls->num_groups is 0 and each out-of-range action here misbehaves. XkbWrapIntoRange divides by zero, which is the reported crash. XkbClampIntoRange is worse: it computes -1, returns it through this function's unsigned type, and the callers truncate it into XkbStateRec's unsigned char group fields as 255, after which XkbComputeCompatState() reads map->groups[255] out of a four element array and reports what it finds to clients in the compat state of every core event. The negative-group case adds zero forever, wedging the server thread, in one path while it holds input_lock. XkbComputeDerivedState() treats group 0 as out of range once num_groups is 0, so all of this is reachable from an ordinary key event. XQuartz gets there because it asks for model "empty", whose keycodes file declares no key names, so a keymap compiled at a client's request has no key definitions at all. Guard the arithmetic itself and not just the places that compute num_groups: groups_wrap selects between these actions and is client settable, and this is exported for DDXes that supply their own controls. Fixes: https://github.com/XQuartz/XQuartz/issues/422 Signed-off-by: Jeremy Huddleston Sequoia <[email protected]> (cherry picked from commit bdb14dce4b62c37abb3ea9e5edba2eca46b2dbab) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2336> - - - - - c1f87673 by Jeremy Huddleston Sequoia at 2026-10-03T18:21:06-07:00 xkb: Default to one group whenever a keymap reports none XkbInitControls() had a fallback to ensure keymaps that defined no symbols at all still resulted in one group. Extend this to cover the case where a keymap reports symbols but no groups. Fixes: https://github.com/XQuartz/XQuartz/issues/422 Signed-off-by: Jeremy Huddleston Sequoia <[email protected]> (cherry picked from commit 8e11715024a5167c9554be7b49c4d6ca0bd2c73b) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2336> - - - - - e43063a2 by Jeremy Huddleston Sequoia at 2026-10-03T18:21:06-07:00 xkb: Never recompute a keymap's group count down to zero Both places that derive ctrls->num_groups from the widest key in the map can arrive at zero. But a keymap in which no key defines any symbols is legal, so ensure we declare at least one group. Fixes: https://github.com/XQuartz/XQuartz/issues/422 Signed-off-by: Jeremy Huddleston Sequoia <[email protected]> (cherry picked from commit aa0bc93d27813a33f3484c861a87c26441b5ea2a) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2336> - - - - - be8da186 by Jeremy Huddleston Sequoia at 2026-10-03T18:21:06-07:00 xkb: Keep the group counts of a loaded keymap in range Clamp the count once per key and use it everywhere the key or the keymap is indexed with it, while still reading every symbol the file claimed so that the stream stays in step and the symbol array is not left short. At the other end, a symbols section in which no key defines any group leaves the count at the zero it was allocated with. This is how XQuartz's keyboard is initialized: model "empty" supplies a symbols section that defines no keys, and a section that defines nothing is still a section, so XkbInitControls() sees XkmSymbolsMask and skips its own single-group default. The device only survives because DarwinKeyboardReloadHandler() immediately pushes a core keymap that raises the count again. Fixes: https://github.com/XQuartz/XQuartz/issues/422 Signed-off-by: Jeremy Huddleston Sequoia <[email protected]> (cherry picked from commit 0c764d98eef507df8e32ac1a84df6782999b5994) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2336> - - - - - 1eb17274 by Alan Coopersmith at 2026-10-03T18:21:06-07:00 xf86: mark wasset unused in xf86UnblockSIGIO() compatibility wrapper Avoids a gcc warning in every file that includes it, whether in the server or drivers: /usr/include/xorg/xf86.h: In function ‘xf86UnblockSIGIO’: /usr/include/xorg/xf86.h:86:55: warning: unused parameter ‘wasset’ [-Wunused-parameter] 86 | static inline _X_DEPRECATED void xf86UnblockSIGIO(int wasset) { input_unlock(); } | ~~~~^~~~~~ Signed-off-by: Alan Coopersmith <[email protected]> (cherry picked from commit 306071c0b9683ef0dfadcfc2dbb78d369680542b) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2336> - - - - - cd6e0524 by stefan11111 at 2026-10-03T18:21:06-07:00 glamor: Set `need_free_region` immediately after pixman region allocation Otherwise, the region would leak when the pixmap is not in gpu memory Signed-off-by: stefan11111 <[email protected]> (cherry picked from commit 41b3d993baf5cbcff7045e63ad0d3d8aebf1dc67) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2336> - - - - - c724006e by Peter Hutterer at 2026-10-07T10:36:43+10:00 xkb: NULL text pointer after free in _CheckSetDoodad error path _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 <[email protected]> Assisted-by: Claude:claude-opus-4-6 (cherry picked from commit 0d1b1b0bad86c9ea2a3b7ca5a70e681dc69f1ecc) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2343> - - - - - 5ec0535a by Peter Hutterer at 2026-10-07T10:36:43+10:00 xkb: allocate names->keys to MAP_LENGTH in XkbAllocNames 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: a3171732da50 ("xkb: Always use MAP_LENGTH keymap size") Signed-off-by: Peter Hutterer <[email protected]> Assisted-by: Claude:claude-opus-4-6 (cherry picked from commit b941a473e06f26a407a9adb15759be79f7418e86) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2343> - - - - - 558ba8f7 by Peter Hutterer at 2026-10-07T10:38:57+10:00 xkb: widen size_syms, num_syms, size_acts, num_acts to unsigned int 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 <[email protected]> Assisted-by: Claude:claude-opus-4-6 (cherry picked from commit 89101a6c6618f543d7502f2077c7ef1a507af256) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2343> - - - - - 927ee128 by Peter Hutterer at 2026-10-07T10:38:57+10:00 xkb: fix CheckKeySyms overwriting request-range symsPerKey entries 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 (cherry picked from commit cea71d0273e4d5092aa9c6a8a770734c8935c02e) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2343> - - - - - 00ce692c by Peter Hutterer at 2026-10-07T10:38:57+10:00 randr: fix size and offset in RRChangeProviderProperty PrependMode RRChangeProviderProperty() has two bugs in the PropModePrepend case: 1. new_value.size is set to 'len' (the new data length) instead of 'total_len' (len + prop_value->size), losing track of the existing data. This also affects PropModeAppend. 2. The old_data offset is computed using prop_value->size instead of len. For PrependMode, the layout should be [new(len)][old(size)], so old_data should start at len * size_in_bytes. These bugs are analogous to the ones fixed in RRChangeOutputProperty(), see commit 541ab2ecd41d ("Xi/randr: fix handling of PropModeAppend/Prepend"). This vulnerability was discovered by: Anonymous working with TrendAI Zero Day Initiative ZDI-CAN-31944 CVE-2026-93521 Assisted-by: Claude:claude-opus-4-6 Signed-off-by: Peter Hutterer <[email protected]> (cherry picked from commit 5dc9efd5a199717b53f70b9c6cd336a522370e46) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2343> - - - - - aa56160f by Peter Hutterer at 2026-10-07T10:38:57+10:00 Xi: validate modifier values in ProcXIPassiveUngrabDevice 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 <[email protected]> Assisted-by: Claude:claude-opus-4-6 (cherry picked from commit 37a1847a60c6799aecf163a5cfa40077a9002675) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2343> - - - - - 3961cdca by Peter Hutterer at 2026-10-07T10:38:57+10:00 glx: validate dataBytes against cmdlen in RenderLarge first request __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 <[email protected]> Assisted-by: Claude:claude-opus-4-6 (cherry picked from commit 2abe4632d793314d3d5f28c19583fb76019f5ce4) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2343> - - - - - a469f98b by Peter Hutterer at 2026-10-07T10:38:57+10:00 present: unlink notifies from window list in present_clear_window_notifies 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 <[email protected]> Assisted-by: Claude:claude-opus-4-6 (cherry picked from commit 1b6955c3108e6b43433aefe860070708e6f43d1b) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2343> - - - - - 9442a53c by Peter Hutterer at 2026-10-07T10:38:57+10:00 dix: remove passive grabs referencing a device on removal 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 (cherry picked from commit be572634158850fff4e9829cee88db08d30c9743) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2343> - - - - - 9c3880d0 by Peter Hutterer at 2026-10-07T10:38:57+10:00 Xi: add bounds check for barrier events in input_constrain_cursor 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 (cherry picked from commit 1f42cc1f00d9c6d46978ae82dba8a52f4d902369) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2343> - - - - - 4c9c345d by Peter Hutterer at 2026-10-07T10:38:57+10:00 Xi: clean up gesture sprite traces in WindowGone 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 (cherry picked from commit efcfd8acc754c5ac4b2555ff375dd5101d735b0a) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2343> - - - - - edc1b378 by Peter Hutterer at 2026-10-07T11:19:46+10:00 xserver 21.1.25 Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2346> - - - - - 52 changed files: - .gitlab-ci.yml - Xext/xtest.c - Xi/exevents.c - Xi/extinit.c - Xi/xibarriers.c - Xi/xipassivegrab.c - Xi/xiquerydevice.c - config/udev.c - configure.ac - dix/devices.c - dix/region.c - dri3/meson.build - exa/exa_accel.c - fb/fb.h - fb/fbgc.c - glamor/glamor_compositerects.c - glx/glxcmds.c - hw/kdrive/src/kinput.c - hw/xfree86/common/xf86.h - hw/xfree86/common/xf86Configure.c - hw/xfree86/common/xf86fbman.c - hw/xfree86/common/xf86platformBus.c - hw/xfree86/drivers/modesetting/dri2.c - hw/xfree86/drivers/modesetting/drmmode_display.c - hw/xfree86/int10/meson.build - hw/xfree86/man/xorg.conf.man - hw/xfree86/os-support/meson.build - hw/xfree86/parser/Files.c - hw/xfree86/parser/Flags.c - hw/xfree86/parser/scan.c - hw/xquartz/GL/indirect.c - hw/xquartz/X11Application.m - hw/xquartz/xpr/dri.c - include/xkbstr.h - meson.build - mi/miarc.c - miext/damage/damage.c - miext/damage/damagestr.h - os/utils.c - present/present_notify.c - randr/rrproviderproperty.c - render/glyph.c - test/string.c - test/xi2/protocol-eventconvert.c - test/xi2/protocol-xiquerydevice.c - xkb/XKBAlloc.c - xkb/XKBMAlloc.c - xkb/ddxBeep.c - xkb/xkb.c - xkb/xkbInit.c - xkb/xkbUtils.c - xkb/xkmread.c The diff was not included because it is too large. View it on GitLab: https://salsa.debian.org/xorg-team/xserver/xorg-server/-/compare/65d790bd208ec380b196eb98f144abb0b32e334d...edc1b378f804ef5bf286318057e0b935f91f22b7 -- View it on GitLab: https://salsa.debian.org/xorg-team/xserver/xorg-server/-/compare/65d790bd208ec380b196eb98f144abb0b32e334d...edc1b378f804ef5bf286318057e0b935f91f22b7 You're receiving this email because of your account on salsa.debian.org. Manage all notifications: https://salsa.debian.org/-/profile/notifications | Help: https://salsa.debian.org/help
