Timo Aaltonen pushed to branch upstream-unstable at X Strike Force / xserver / xorg-server
Commits: d7c83b88 by Alan Coopersmith at 2025-11-30T17:21:49+00:00 Create a SECURITY.md file Provide information on where to report or learn of security bugs, and what we do or do not consider to be a security bug. Signed-off-by: Alan Coopersmith <[email protected]> (cherry picked from commit a5047d4a6576630d0e15b8f145a44ff6ebe55369) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2106> - - - - - d5aefa60 by Alan Coopersmith at 2025-11-30T17:21:49+00:00 Makefile.am: add SECURITY.md to EXTRA_DIST Include it in the tarballs generated by automake Signed-off-by: Alan Coopersmith <[email protected]> Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2106> - - - - - 09eb9aa3 by Jeremy Huddleston Sequoia at 2026-03-24T20:59:01-07:00 rootless: Fix Glyphs damage bounding box to correctly compute union RootlessGlyphs used max() for box.x1 and box.y1 when accumulating the bounding box across glyphs in a list. Computing the union of bounding boxes requires min() for the lower coordinate corner and max for the higher coordinate corner. Signed-off-by: Jeremy Huddleston Sequoia <[email protected]> (cherry picked from commit e8936920ee392086f3af42d86f533bafe589fdb2) - - - - - d7279b8e by Jeremy Huddleston Sequoia at 2026-03-24T20:59:02-07:00 rootless: Add Trapezoids, Triangles, and CompositeRects wrapping The Render extension's Trapezoids and Triangles operations (fbTrapezoids, fbTriangles) render directly via pixman through fbShapes without going through ps->Composite, so RootlessComposite never fires for these operations. This means RootlessStartDrawing is not called and the macOS compositor is not notified of changed pixels. Add RootlessTrapezoids and RootlessTriangles wrappers following the same pattern as RootlessComposite: call RootlessStartDrawing before the operation, then compute the bounding box via miTrapezoidBounds or miTriangleBounds and call RootlessDamageBox after. The default miTriStrip and miTriFan implementations decompose their input into triangles and dispatch through ps->Triangles, so the RootlessTriangles wrapper covers TriStrip and TriFan as well. Also add a RootlessCompositeRects wrapper as defense-in-depth. The current miCompositeRects implementation already has partial rootless coverage: PictOpSrc/PictOpClear go through the GC layer, and other ops route through CompositePicture -> RootlessComposite. Wrapping at the PictureScreen level ensures robustness regardless of the underlying implementation. Fixes [1/2]: https://github.com/XQuartz/XQuartz/issues/31 Signed-off-by: Jeremy Huddleston Sequoia <[email protected]> (cherry picked from commit 40b762cf6d4c861ece9a07855d8005e4280e8086) - - - - - ef781045 by Jeremy Huddleston Sequoia at 2026-03-24T20:59:03-07:00 rootless: Protect alpha channel for Render operations The Render extension operates on PictFormats rather than GC, so it bypasses the rootless layer's GC-based alpha protection (ROOTLESS_PROTECT_ALPHA). Depth-24 windows use PICT_x8r8g8b8 where the 'x' tells pixman the high byte is padding it may freely zero. The macOS compositor needs this byte to be 0xFF (opaque). Before each Render operation that targets a rootless window, temporarily upgrade the destination Picture's format from PICT_x8r8g8b8 to PICT_a8r8g8b8. This tells pixman that the alpha channel is significant and must not be optimized away. The format is restored after the operation completes. This parallels how ROOTLESS_PROTECT_ALPHA handles GC operations (by masking alpha out of the planemask) and how ROOTLESS_SAFEALPHA handles PaintWindow (by forcing alpha in solid fills). The save/restore approach is analogous to rootlessGC.c's GC_SAVE / GC_RESTORE pattern. Fixes [2/2]: https://github.com/XQuartz/XQuartz/issues/31 Signed-off-by: Jeremy Huddleston Sequoia <[email protected]> (cherry picked from commit d2e83a266c65437902f4a5c85043fa835b5c6013) - - - - - 65f4ce96 by Jeremy Huddleston Sequoia at 2026-03-25T23:47:59-07:00 xquartz: Bump copyrights in Info.plist to 2026 Signed-off-by: Jeremy Huddleston Sequoia <[email protected]> (cherry picked from commit fbff1312ce74326596eb4c4d585f7218ecfa2ad4) - - - - - 3b92ab18 by Alan Coopersmith at 2026-03-28T16:39:59+00:00 xfree86: Fix builds with gcc -Wpedantic ../hw/xfree86/loader/loadmod.c:85:33: warning: ISO C forbids empty initializer braces before C23 [-Wpedantic] 85 | static int ModuleDuplicated[] = { }; | ^ ../hw/xfree86/loader/loadmod.c:85:12: error: zero or negative size array ‘ModuleDuplicated’ 85 | static int ModuleDuplicated[] = { }; | ^~~~~~~~~~~~~~~~ Signed-off-by: Alan Coopersmith <[email protected]> (cherry picked from commit d03c84b57f1455b20518781026777b938194b2a4) (cherry picked from commit 3e0f37c95c92829e338a910379440ba9b4f4170d) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146> - - - - - ec4e918d by Takashi Yano at 2026-03-28T16:39:59+00:00 Fix mach64 driver crash Due to lack of iopl(3), mach64 driver crashes when ior(BUS_CNTL) is called. Since BUS_CNTL is out of the range 0x0000-0x03ff, ioperm(0, 1024, 1) is not sufficient and the ior() causes access violation. This patch reintroduce iopl(3) call in the function hwEnableIO(). Addresses: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1110521 Fixes: a0f738a67327 ("Fixed ioperm calls in hwEnableIO") Signed-off-by: Takashi Yano <[email protected]> (cherry picked from commit 3b39aebf984bf2d5a32fd2372d658dd1abef05d2) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146> - - - - - c0146196 by Alan Coopersmith at 2026-03-28T16:39:59+00:00 dix: set errorValue correctly when XID lookup fails in ChangeGCXIDs() dixLookupResourceByType always overwrites the pointer passed in as the first arg, so we shouldn't use the union it's in after that to get the requested XID value to put in the errorValue. Closes: #1857 Fixes: 2d7eb4a19 ("Pre-validate ChangeGC XIDs.") Reported-by: Mouse <[email protected]> Signed-off-by: Alan Coopersmith <[email protected]> (cherry picked from commit ac42c39145849588544ad10812e5a8ae76bf1114) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146> - - - - - ff10e6d0 by Mikhail Dmitrichenko at 2026-03-28T16:39:59+00:00 os: avoid closing null fd at Fopen In `Fopen` function variable `iop` may store NULL as a result of `fopen` call. In this case, if later privileges couldn't be restored (`seteuid` call fails), further `fclose(iop)` call will cause runtime error. This commit adds check `iop` for NULL before calling `fclose` to prevent potential NULL pointer dereference. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Mikhail Dmitrichenko <[email protected]> (cherry picked from commit f83807647e171def9244a7f1d8d9af8e8e79f847) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146> - - - - - 123f50ac by Mikhail Dmitrichenko at 2026-03-28T16:39:59+00:00 render: fix multiple mem leaks on err paths Free nested allocations when initialization fails. Several code paths returned early on error without releasing memory owned by embedded structures, leading to leaks. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Mikhail Dmitrichenko <[email protected]> (cherry picked from commit 809402414e4b84ad5c084221c7b4da9bd2c5d55d) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146> - - - - - 9ee6ae72 by Mikhail Dmitrichenko at 2026-03-28T16:39:59+00:00 dix: avoid null ptr deref at doListFontsAndAliases In the `doListFontsAndAliases` function in dixfonts.c, when a font alias is encountered (`err == FontNameAlias`) as a result of `list_next_font_or_alias` call, the code allocates memory for `resolved` variable (`resolvedlen + 1` bytes) for storing target font name. In this case, if the `malloc(resolvedlen + 1)` call fails, `resolved` remains NULL. Later, when check (`else if (err == FontNameAlias)`) is TRUE, the code uses `memcpy` to copy nullable `resolved` into `tmp_pattern` without checking if `resolved` is NULL, so there is a potential null ptr dereference. This commit replaces `malloc` with `XNFalloc` for allocating memory for `resolved`. `XNFalloc` will internally check result of `malloc` and stop program execution if allocation was failed, preventing potential NULL dereferencing. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Mikhail Dmitrichenko <[email protected]> (cherry picked from commit 0237462d326c78868c83b6eda35a9d35725f3b33) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146> - - - - - 3069f64d by quantenzitrone at 2026-03-28T16:39:59+00:00 COPYING: add missing paragraph to SGI-B-2.0 all files that this license applies to include the last paragraph: - glx/xfont.c - glx/unpack.h - glx/singlesize.h - glx/singlesize.c - glx/singlepixswap.c - glx/singlepix.c - glx/single2swap.c - glx/single2.c - glx/rensize.c - glx/renderpixswap.c - glx/renderpix.c - glx/render2swap.c - glx/render2.c - glx/glxutil.h - glx/glxdrawable.h - glx/glxserver.h - glx/glxcontext.h - glx/glxscreens.h - glx/glxscreens.c - glx/glxcmdsswap.c - glx/glxext.h - glx/glxcmds.c - glx/glxext.c the paragraph was likely accidentally missed when the license changed from SGI-B-1.0 to SGI-B-2.0 in https://gitlab.freedesktop.org/xorg/xserver/-/commit/ed9aecf8517bf74e943e3e5dd3ee407524e8f122 (cherry picked from commit 6105e5b1338314aca400ff78452ec029c78604e7) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146> - - - - - dd924b16 by quantenzitrone at 2026-03-28T16:39:59+00:00 COPYING: add author to HPND-sell-MIT-disclaimer-xserver the license notice comes from these files: - dix/registry.c - Xext/xselinuxint.h - Xext/xselinux_label.c - Xext/xselinux_hooks.c - Xext/xselinux_ext.c - Xext/xselinux.h - Xext/xacestr.h - Xext/xace.h - Xext/xace.c while this is not like the standard `Copyright (C)` lines I think it still belongs to the license, even if just to make it more clearly separate from the MIT license above (cherry picked from commit fff00233394131a48f075d052cb8239ab875c8d6) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146> - - - - - ce300ed2 by hongao at 2026-03-28T16:39:59+00:00 randr: clear primary screen's primaryOutput when the output is deleted This fix use after free when a pluggable gpu screen (such as displaylink) was set as primary screen and unpluged. gdb backtrace: #0 OssigHandler (signo=11, sip=0x7fff2e0a50f0, unused=0x7fff2e0a4fc0) at ../../../../os/osinit.c:138 #1 <signal handler called> #2 rrGetscreenResources (client=0x3195160, query=0) at ../../../../randr/rrscreen.c:577 #3 0x0000000000562bae in ProcRRGetscreenResourcesCurrent (client=0x3195160) at ../../../../randr/rrscreen.c:652 #4 OxOOOOB0000054de63 in ProcRRDispatch (client=0x3195160) at ../../../../randr/randr.c:717 #5 0x00000000004322c6 in Dispatch () at ../../../../dix/dispatch.c:485 #6 0x0900900990443139 in dix_main (argc=12, argv=0x7fff2e0a5f78, envp=0x7fff2e0a5fe0) at ../../../../dix/main.c:276 #7 0X0000000000421d9a in main (argc=12, argv=0x7fff2e0a5f78, envp=0x7fff2e0a5fe0) at ../../../../dix/stubmain.c:34 Signed-off-by: hongao <[email protected]> (cherry picked from commit 1443fd34ea37e8c7cedfac446e4a34205c5fbbb0) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146> - - - - - fe14f010 by Matthieu Herrb at 2026-03-28T16:40:00+00:00 Better fix for xf86CompatOut() when there are no privates XF86_CRTC_CONFIG_PTR() will derefence privates[-1] in this case. Signed-off-by: Matthieu Herrb <[email protected]> (cherry picked from commit 75d70612888f18339703315549db781a22c0cb23) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146> - - - - - cc3a8739 by Benjamin Valentin at 2026-03-28T16:40:00+00:00 xf86: check return value of XF86_CRTC_CONFIG_PTR in xf86CompatOutput() If privates[xf86CrtcConfigPrivateIndex].ptr is NULL, this will cause a segfault. Possible fix for !1241 Signed-off-by: Benjamin Valentin <[email protected]> (cherry picked from commit 907c501926775fdbc9a8bfcfd3d64ac3d5502775) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146> - - - - - 447fec7d by Alan Coopersmith at 2026-03-28T16:40:00+00:00 os: include <assert.h> in ospoll.c Fixes build failure in mingw-cross-build: ../os/ospoll.c: In function ‘ospoll_destroy’: ../os/ospoll.c:266:9: error: implicit declaration of function ‘assert’ [-Werror=implicit-function-declaration] 266 | assert (ospoll->num == 0); | ^~~~~~ ../os/ospoll.c:59:1: note: ‘assert’ is defined in header ‘<assert.h>’; did you forget to ‘#include <assert.h>’? 58 | #include "xserver_poll.h" +++ |+#include <assert.h> 59 | #define POLL 1 ../os/ospoll.c:266:9: warning: nested extern declaration of ‘assert’ [-Wnested-externs] 266 | assert (ospoll->num == 0); | ^~~~~~ Signed-off-by: Alan Coopersmith <[email protected]> (cherry picked from commit 7f8570bfa16bd41e4536385b46742cc316546529) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146> - - - - - 33eee35e by Alan Coopersmith at 2026-03-28T16:40:00+00:00 os: make FormatInt64() handle LONG_MIN correctly When compiling with gcc 15.2.0 using -O3 -m64 on Solaris SPARC & x64, we'd get a test failure of: Assertion failed: strcmp(logmsg, expected) == 0, file ../test/signal-logging.c, line 339, function logging_format because 'num *= 1' produced a value that was out of the range of the int64_t it was being stored in. (Compiling with -O2 worked fine with the same compiler/configuration/platform though.) Signed-off-by: Alan Coopersmith <[email protected]> (cherry picked from commit 7f68b588657ea14050971efa86682e55e2c7e21b) (cherry picked from commit 3eac9393d734a1aa8342179f98e30569da70db95) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146> - - - - - 032715f2 by Twaik Yont at 2026-03-28T16:40:00+00:00 os: use close-on-exec for X server socket to prevent fd leaks In most typical Linux X servers (like Xvfb, Xephyr, or Xwayland), no child process outlives the server, so this issue rarely arises. However, in embedded X servers (based on Xvfb or Kdrive) or in custom Xorg modules, the server might launch a long-running command with regular fork+exec calls. If the X server crashes or exits while that command is still running (for example, it spawns a tombstone generator or any process that hangs or turns to zombie), the file descriptor associated with the abstract socket can remain open in the child process. This leads to the kernel refusing to allow another X server to bind the same socket until the child process terminates (because there is no explicit way to unlink abstract socket, unlike Unix socket). By marking the file descriptor as close-on-exec, we ensure it is automatically closed in child processes, preserving the ability of a new X server process to bind the socket immediately. Signed-off-by: Twaik Yont <[email protected]> (cherry picked from commit 5568b0f83f388a295f42d49411ced17387043794) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146> - - - - - d6d9bead by Alan Coopersmith at 2026-03-28T16:40:00+00:00 xf86bigfont: fix -Wimplicit-function-declaration error Build breaks with gcc 14 & later when xf86bigfont is enabled: ../Xext/xf86bigfont.c: In function ‘XFree86BigfontExtensionInit’: ../Xext/xf86bigfont.c:709:28: error: implicit declaration of function ‘xfont2_allocate_font_private_index’; did you mean ‘AllocateFontPrivateIndex’? [-Wimplicit-function-declaration] 709 | FontShmdescIndex = xfont2_allocate_font_private_index(); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | AllocateFontPrivateIndex Fixes: 05a793f5b ("dix: Switch to the libXfont2 API (v2)") Signed-off-by: Alan Coopersmith <[email protected]> (cherry picked from commit 0617f6075b6a867c90912ccaf9de2200d06a5419) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146> - - - - - 7a6c6bf9 by Alan Coopersmith at 2026-03-28T16:40:00+00:00 dix: Fix builds with meson -Dxace=false -Dwerror=true CI meson-disable-options builds were failing with: ../dix/events.c: In function ‘CoreEnterLeaveEvent’: ../dix/events.c:4723:19: error: unused variable ‘client’ [-Werror=unused-variable] 4723 | ClientPtr client = grab ? rClient(grab) : wClient(pWin); | ^~~~~~ ../dix/events.c: In function ‘CoreFocusEvent’: ../dix/events.c:4834:19: error: unused variable ‘client’ [-Werror=unused-variable] 4834 | ClientPtr client = wClient(pWin); | ^~~~~~ Signed-off-by: Alan Coopersmith <[email protected]> (cherry picked from commit 6611caf828af4833d59cd41f8c64a910f1edcac9) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146> - - - - - 13cb37f1 by Alan Coopersmith at 2026-03-28T16:40:00+00:00 meson: don't build xselinux if xace is disabled xselinux requires xace to build Signed-off-by: Alan Coopersmith <[email protected]> (cherry picked from commit 7b15321b3b0e40244af1488f4ee1cd4453a78bc8) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146> - - - - - 91af36ed by Alan Coopersmith at 2026-03-28T16:40:00+00:00 glamor: handle potential NULL return from GetPictureScreenIfSet() Unlike GetPictureScreen(), GetPictureScreenIfSet() checks if the private key is registered, and returns NULL if it is not. Reported in #1817: xwayland-24.1.6/redhat-linux-build/../glamor/glamor.c:926:5: warning[-Wanalyzer-null-dereference]: dereference of NULL ‘ps’ Signed-off-by: Alan Coopersmith <[email protected]> (cherry picked from commit 69b48423bd66f04bac8a633004ebc8e6e691756f) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146> - - - - - b0020150 by Alan Coopersmith at 2026-03-28T16:40:00+00:00 glamor: handle allocation failure in glamor_create_pixmap() Reported by gcc 15.1: ../glamor/glamor.c: In function ‘glamor_create_pixmap’: ../glamor/glamor.c:233:23: warning: potential null pointer dereference [-Wnull-dereference] 233 | pixmap_priv->type = GLAMOR_TEXTURE_ONLY; | ~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~ ../glamor/glamor.c:228:26: warning: potential null pointer dereference [-Wnull-dereference] 228 | pixmap_priv->is_cbcr = (GLAMOR_CREATE_FORMAT_CBCR & usage) == GLAMOR_CREATE_FORMAT_CBCR; Signed-off-by: Alan Coopersmith <[email protected]> (cherry picked from commit cc647f23679ae2beb7b971aa7d1203375c25bb55) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146> - - - - - 733eab33 by Alan Coopersmith at 2026-03-28T16:40:00+00:00 glamor: silence false positive in glamor_validate_gc() We know that if gc->tileIsPixel is false, then gc->tile.pixmap must be a valid pixmap, but gcc's static analyzer doesn't and needs to be told. Silences false positive reported in #1817: xwayland-24.1.6/redhat-linux-build/../glamor/glamor_core.c:205:19: warning[-Wanalyzer-null-dereference]: dereference of NULL ‘0’ Signed-off-by: Alan Coopersmith <[email protected]> (cherry picked from commit a79bdc495eaabd770cec03badd74c3b023877ba1) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146> - - - - - e9d45963 by Alan Coopersmith at 2026-03-28T16:40:00+00:00 glamor: handle allocation failures in glamor_largepixmap.c Reported in #1817: xwayland-24.1.6/redhat-linux-build/../glamor/glamor_largepixmap.c:130:17: warning[-Wanalyzer-possible-null-dereference]: dereference of possibly-NULL ‘clipped_regions’ xwayland-24.1.6/redhat-linux-build/../glamor/glamor_largepixmap.c:235:13: warning[-Wanalyzer-possible-null-dereference]: dereference of possibly-NULL ‘result_regions’ xwayland-24.1.6/redhat-linux-build/../glamor/glamor_largepixmap.c:365:9: warning[-Wanalyzer-possible-null-dereference]: dereference of possibly-NULL ‘clipped_regions’ xwayland-24.1.6/redhat-linux-build/../glamor/glamor_largepixmap.c:1175:9: warning[-Wanalyzer-possible-null-dereference]: dereference of possibly-NULL ‘source_pixmap_priv’ Signed-off-by: Alan Coopersmith <[email protected]> (cherry picked from commit 84cf20e6ddacbfc62637f156a92d673574c43604) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146> - - - - - 0ead6574 by Alan Coopersmith at 2026-03-28T16:40:00+00:00 glamor: avoid null dereference in glamor_dash_setup() Reported in #1817: xwayland-24.1.6/redhat-linux-build/../glamor/glamor_dash.c:152:10: warning[-Wanalyzer-null-dereference]: dereference of NULL ‘0’ Signed-off-by: Alan Coopersmith <[email protected]> (cherry picked from commit c6522229b86f9087347b17280b6e5f19345baf9a) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146> - - - - - b94cdc40 by Alan Coopersmith at 2026-03-28T16:40:00+00:00 glamor: avoid null dereference in glamor_composite_clipped_region() Reported in #1817: xwayland-24.1.6/redhat-linux-build/../glamor/glamor_render.c:1577:21: warning[-Wanalyzer-null-dereference]: dereference of NULL ‘0’ Signed-off-by: Alan Coopersmith <[email protected]> (cherry picked from commit 6a4ec30af49bcbf61cf8ebc3a8f5541abac9024d) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146> - - - - - 37977717 by Alan Coopersmith at 2026-03-28T16:40:00+00:00 glamor: avoid double free in glamor_make_pixmap_exportable() Reported by gcc 15.1: ../glamor/glamor_egl.c:320:9: warning: double-‘free’ of ‘modifiers’ [CWE-415] [-Wanalyzer-double-free] [...] │ 732 |│ free(*modifiers); │ |│ ~~~~~~~~~~~~~~~~ │ |│ | │ |└───────>(25) ...to here │ | (26) first ‘free’ here [...] │ 320 | free(modifiers); │ | ~~~~~~~~~~~~~~~ │ | | │ | (28) ⚠️ second ‘free’ here; first ‘free’ was at (26) Fixes: cef12efc1 ("glamor: Implement GetSupportedModifiers") Signed-off-by: Alan Coopersmith <[email protected]> (cherry picked from commit 3e9baa20f39b0502efdaf48c2ca7e2f58d1e3120) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146> - - - - - d2f1d74f by Alexander Melnyk at 2026-03-28T16:40:00+00:00 xkb: Fix locked/latched indicator desync across multiple keyboards When a group indicator (or a latched indicator of any kind) is defined, e.g.: indicator "Scroll Lock" { groups = Group2; } the logical and physical indicator state may desync across multiple connected keyboards. This is caused by XkbPushLockedStateToSlaves only pushing locked_mods to the slave devices. Pushing locked_group (as well as latched groups/mods) along with locked_mods resolves the issue. The issue is not observed with API calls because a different code path is taken (avoiding XkbPushLockedStateToSlaves altogether). Signed-off-by: Alexander Melnyk <[email protected]> (cherry picked from commit 36a7fdd3152a0763636fb33a018517d831f64ee6) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146> - - - - - bdc7eb8f by Pierre Le Marre at 2026-03-28T16:40:00+00:00 xkb: Fix key type without level names in XkbCopyKeymap A key type that has no level names is legit. Before this commit, `XkbCopyKeymap` would make such level inconsistent by setting its number of levels to 0 while keeping its map entries. It suffices to clear the names array. Fixed by copying the level count from the source type. WARNING: this will trigger an error in `XkbGetNames`, which worked before this commit only by chance. This is fixed in the next commit. (cherry picked from commit 12605989af6e71651c1fbb125277a953259ab7b7) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146> - - - - - 5ebf0a9d by Pierre Le Marre at 2026-03-28T16:40:00+00:00 xkb: Fix serialization of key type without level names Before this commit the count of key type level names was wrongly set in `XkbGetNames`: for key type without names, it was set to the level count, while it should be 0: - `XkbComputeGetNamesReplySize()` does not account key type without level names; - `XkbSendNames()` does not write any level entry for key types without level names. This causes a mismatch offset while parsing the response and its processing would ultimately fail. Fixed by setting the correct level name count: 0 if there is no level name, else the number of levels. (cherry picked from commit c49cbc176a65892fb1109fee5c6e8316a771f5e6) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146> - - - - - fd9f9f74 by Alan Coopersmith at 2026-03-28T16:40:00+00:00 os: fix sha1 build error with Nettle 4.0 Nettle 2.6 (released in 2013) split the sha.h header into sha1.h & sha2.h, but left the sha.h header for compatibility until the recent Nettle 4.0 release finally removed it. Nettle 4.0 also dropped the length argument from the sha1_digest function. Closes: #1871 Signed-off-by: Alan Coopersmith <[email protected]> Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2146> - - - - - 432cb931 by Peter Harris at 2026-04-14T15:12:24+02:00 xkb: fix buffer re-use in _XkbSetCompatMap If the "compat" buffer has previously been truncated, there will be unused space in the buffer. The code uses this space, but does not update the number of valid entries in the buffer. In the best case, this leads to the new compat entries being ignored. In the worst case, if there are any "skipped" compat entries, the number of valid entries will be corrupted, potentially leading to a buffer read overrun when processing a future request. Set the number of used "compat" entries when re-using previously allocated space in the buffer. CVE-2026-33999, ZDI-CAN-28593 This vulnerability was discovered by: Jan-Niklas Sohn working with TrendAI Zero Day Initiative Signed-off-by: Peter Harris <[email protected]> Acked-by: Olivier Fourdan <[email protected]> (cherry picked from commit b024ae1749ee58c6fbf863b9a1f5dc440fee2e1b) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2178> - - - - - a48d67f3 by Olivier Fourdan at 2026-04-14T15:12:24+02:00 xkb: Fix bounds check in _CheckSetGeom() As reported by valgrind: == Conditional jump or move depends on uninitialised value(s) == at 0x5CBE66: SrvXkbAddGeomKeyAlias (XKBGAlloc.c:585) == by 0x5AC7D5: _CheckSetGeom (xkb.c:5607) == by 0x5AC952: _XkbSetGeometry (xkb.c:5643) == by 0x5ACB58: ProcXkbSetGeometry (xkb.c:5684) == by 0x5B0DAC: ProcXkbDispatch (xkb.c:7070) == by 0x4A28C5: Dispatch (dispatch.c:553) == by 0x4B0B24: dix_main (main.c:274) == by 0x42915E: main (stubmain.c:34) == Uninitialised value was created by a heap allocation == at 0x4840B26: malloc (vg_replace_malloc.c:447) == by 0x5E13B0: AllocateInputBuffer (io.c:981) == by 0x5E05CD: InsertFakeRequest (io.c:516) == by 0x4AA860: NextAvailableClient (dispatch.c:3629) == by 0x5DE0D7: AllocNewConnection (connection.c:628) == by 0x5DE2C6: EstablishNewConnections (connection.c:692) == by 0x5DE600: HandleNotifyFd (connection.c:809) == by 0x5E2598: ospoll_wait (ospoll.c:660) == by 0x5DA00C: WaitForSomething (WaitFor.c:208) == by 0x4A26E5: Dispatch (dispatch.c:493) == by 0x4B0B24: dix_main (main.c:274) == by 0x42915E: main (stubmain.c:34) Each key alias entry contains two key names (the alias and the real key name), each of size XkbKeyNameLength. The current bounds check only validates the first name, allowing XkbAddGeomKeyAlias to potentially read uninitialized memory when accessing the second name at &wire[XkbKeyNameLength]. To fix this, change the value to check to use 2 * XkbKeyNameLength to validate the bounds. CVE-2026-34000, ZDI-CAN-28679 This vulnerability was discovered by: Jan-Niklas Sohn working with TrendAI Zero Day Initiative Signed-off-by: Olivier Fourdan <[email protected]> Acked-by: Peter Hutterer <[email protected]> (cherry picked from commit 81b6a34f90b28c32ad499a78a4f391b7c06daea2) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2178> - - - - - 70aad886 by Olivier Fourdan at 2026-04-14T15:12:24+02:00 miext/sync: Fix use-after-free in miSyncTriggerFence() As reported by valgrind: == Invalid read of size 8 == at 0x568C14: miSyncTriggerFence (misync.c:140) == by 0x540688: ProcSyncTriggerFence (sync.c:1957) == by 0x540CCC: ProcSyncDispatch (sync.c:2152) == by 0x4A28C5: Dispatch (dispatch.c:553) == by 0x4B0B24: dix_main (main.c:274) == by 0x42915E: main (stubmain.c:34) == Address 0x17e35488 is 8 bytes inside a block of size 16 free'd == at 0x4843E43: free (vg_replace_malloc.c:990) == by 0x53D683: SyncDeleteTriggerFromSyncObject (sync.c:169) == by 0x53F14D: FreeAwait (sync.c:1208) == by 0x4DFB06: doFreeResource (resource.c:888) == by 0x4DFC59: FreeResource (resource.c:918) == by 0x53E349: SyncAwaitTriggerFired (sync.c:701) == by 0x568C52: miSyncTriggerFence (misync.c:142) == by 0x540688: ProcSyncTriggerFence (sync.c:1957) == by 0x540CCC: ProcSyncDispatch (sync.c:2152) == by 0x4A28C5: Dispatch (dispatch.c:553) == by 0x4B0B24: dix_main (main.c:274) == by 0x42915E: main (stubmain.c:34) == Block was alloc'd at == at 0x4840B26: malloc (vg_replace_malloc.c:447) == by 0x5E50E1: XNFalloc (utils.c:1129) == by 0x53D772: SyncAddTriggerToSyncObject (sync.c:206) == by 0x53DCA8: SyncInitTrigger (sync.c:414) == by 0x5409C7: ProcSyncAwaitFence (sync.c:2089) == by 0x540D04: ProcSyncDispatch (sync.c:2160) == by 0x4A28C5: Dispatch (dispatch.c:553) == by 0x4B0B24: dix_main (main.c:274) == by 0x42915E: main (stubmain.c:34) When walking the list of fences to trigger, miSyncTriggerFence() may call TriggerFence() for the current trigger, which end up calling the function SyncAwaitTriggerFired(). SyncAwaitTriggerFired() frees the entire await resource, which removes all triggers from that await - including pNext which may be another trigger from the same await attached to the same fence. On the next iteration, ptl = pNext points to freed memory... To avoid the issue, we need to restart the iteration from the beginning of the list each time a trigger fires, since the callback can modify the list. CVE-2026-34001, ZDI-CAN-28706 This vulnerability was discovered by: Jan-Niklas Sohn working with TrendAI Zero Day Initiative Signed-off-by: Olivier Fourdan <[email protected]> Acked-by: Peter Hutterer <[email protected]> (cherry picked from commit f19ab94ba9c891d801231654267556dc7f32b5e0) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2178> - - - - - 5328a544 by Olivier Fourdan at 2026-04-14T15:12:24+02:00 xkb: Fix out-of-bounds read in CheckModifierMap() As reported by valgrind: == Conditional jump or move depends on uninitialised value(s) == at 0x547E5B: CheckModifierMap (xkb.c:1972) == by 0x54A086: _XkbSetMapChecks (xkb.c:2574) == by 0x54A845: ProcXkbSetMap (xkb.c:2741) == by 0x556EF4: ProcXkbDispatch (xkb.c:7048) == by 0x454A8C: Dispatch (dispatch.c:553) == by 0x462CEB: dix_main (main.c:274) == by 0x405EA7: main (stubmain.c:34) == Uninitialised value was created by a heap allocation == at 0x4840B26: malloc (vg_replace_malloc.c:447) == by 0x592D5A: AllocateInputBuffer (io.c:981) == by 0x591F77: InsertFakeRequest (io.c:516) == by 0x45CA27: NextAvailableClient (dispatch.c:3629) == by 0x58FA81: AllocNewConnection (connection.c:628) == by 0x58FC70: EstablishNewConnections (connection.c:692) == by 0x58FFAA: HandleNotifyFd (connection.c:809) == by 0x593F42: ospoll_wait (ospoll.c:660) == by 0x58B9B6: WaitForSomething (WaitFor.c:208) == by 0x4548AC: Dispatch (dispatch.c:493) == by 0x462CEB: dix_main (main.c:274) == by 0x405EA7: main (stubmain.c:34) The issue is that the loop in CheckModifierMap() reads from wire without verifying that the data is within the request bounds. The req->totalModMapKeys value could exceed the actual data provided, causing reads of uninitialized memory. To fix that issue, we add a bounds check using _XkbCheckRequestBounds, but for that, we need to also pass a ClientPtr parameter, which is not a problem since CheckModifierMap() is a private, static function. CVE-2026-34002, ZDI-CAN-28737 This vulnerability was discovered by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative Signed-off-by: Olivier Fourdan <[email protected]> Acked-by: Peter Hutterer <[email protected]> (cherry picked from commit f056ce1cc96ed9261052c31524162c78e458f98c) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2178> - - - - - 905194d1 by Olivier Fourdan at 2026-04-14T15:12:24+02:00 xkb: Add additional bound checking in CheckKeyTypes() The function CheckKeyTypes() will loop over the client's request but won't perform any additional bound checking to ensure that the data read remains within the request bounds. As a result, a specifically crafted request may cause CheckKeyTypes() to read past the request data, as reported by valgrind: == Invalid read of size 2 == at 0x5A3D1D: CheckKeyTypes (xkb.c:1694) == by 0x5A6A9C: _XkbSetMapChecks (xkb.c:2515) == by 0x5A759E: ProcXkbSetMap (xkb.c:2736) == by 0x5BF832: SProcXkbSetMap (xkbSwap.c:245) == by 0x5C05ED: SProcXkbDispatch (xkbSwap.c:501) == by 0x4A20DF: Dispatch (dispatch.c:551) == by 0x4B03B4: dix_main (main.c:277) == by 0x428941: main (stubmain.c:34) == Address is 30 bytes after a block of size 28,672 in arena "client" == == Invalid read of size 2 == at 0x5A3AB6: CheckKeyTypes (xkb.c:1669) == by 0x5A6A9C: _XkbSetMapChecks (xkb.c:2515) == by 0x5A759E: ProcXkbSetMap (xkb.c:2736) == by 0x5BF832: SProcXkbSetMap (xkbSwap.c:245) == by 0x5C05ED: SProcXkbDispatch (xkbSwap.c:501) == by 0x4A20DF: Dispatch (dispatch.c:551) == by 0x4B03B4: dix_main (main.c:277) == by 0x428941: main (stubmain.c:34) == Address is 2 bytes after a block of size 28,672 alloc'd == at 0x4848897: realloc (vg_replace_malloc.c:1804) == by 0x5E357A: ReadRequestFromClient (io.c:336) == by 0x4A1FAB: Dispatch (dispatch.c:519) == by 0x4B03B4: dix_main (main.c:277) == by 0x428941: main (stubmain.c:34) == == Invalid write of size 2 == at 0x5A3AD7: CheckKeyTypes (xkb.c:1669) == by 0x5A6A9C: _XkbSetMapChecks (xkb.c:2515) == by 0x5A759E: ProcXkbSetMap (xkb.c:2736) == by 0x5BF832: SProcXkbSetMap (xkbSwap.c:245) == by 0x5C05ED: SProcXkbDispatch (xkbSwap.c:501) == by 0x4A20DF: Dispatch (dispatch.c:551) == by 0x4B03B4: dix_main (main.c:277) == by 0x428941: main (stubmain.c:34) == Address is 2 bytes after a block of size 28,672 alloc'd == at 0x4848897: realloc (vg_replace_malloc.c:1804) == by 0x5E357A: ReadRequestFromClient (io.c:336) == by 0x4A1FAB: Dispatch (dispatch.c:519) == by 0x4B03B4: dix_main (main.c:277) == by 0x428941: main (stubmain.c:34) == To avoid that issue, add additional bounds checking within the loops by calling _XkbCheckRequestBounds() and report an error if we are to read past the client's request. CVE-2026-34003, ZDI-CAN-28736 This vulnerability was discovered by: Jan-Niklas Sohn working with TrendAI Zero Day Initiative Signed-off-by: Olivier Fourdan <[email protected]> Acked-by: Peter Hutterer <[email protected]> (cherry picked from commit b85b00dd7b9eee05e3c12e7ad1fce4fc6671507b) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2178> - - - - - e8674488 by Olivier Fourdan at 2026-04-14T15:12:24+02:00 xkb: Add more _XkbCheckRequestBounds() Similar to the recent fixes, add more _XkbCheckRequestBounds() to the functions that loop over the request data, i.e.: * CheckKeySyms() * CheckKeyActions() * CheckKeyBehaviors() * CheckVirtualMods() * CheckKeyExplicit() * CheckVirtualModMap() * _XkbSetMapChecks() All these are static functions so we can add the client to the parameters without breaking any API. See also: CVE-2026-34003, ZDI-CAN-28736, CVE-2026-34002, ZDI-CAN-28737 v2: Check for "nSyms != 0" in CheckKeySyms() to avoid false positives. Signed-off-by: Olivier Fourdan <[email protected]> Acked-by: Peter Hutterer <[email protected]> (cherry picked from commit d38c563fab5c4a554e0939da39e4d1dadef7cbae) Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2178> - - - - - 38efdcad by Olivier Fourdan at 2026-04-14T15:12:24+02:00 xserver 21.1.22 Signed-off-by: Olivier Fourdan <[email protected]> Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2178> - - - - - 31 changed files: - COPYING - Makefile.am - + SECURITY.md - Xext/xf86bigfont.c - configure.ac - dix/dixfonts.c - dix/events.c - dix/gc.c - glamor/glamor.c - glamor/glamor_core.c - glamor/glamor_dash.c - glamor/glamor_egl.c - glamor/glamor_largepixmap.c - glamor/glamor_render.c - hw/xfree86/loader/loadmod.c - hw/xfree86/modes/xf86Crtc.h - hw/xfree86/os-support/linux/lnx_video.c - hw/xquartz/bundle/Info.plist.cpp - meson.build - miext/rootless/rootlessCommon.h - miext/rootless/rootlessScreen.c - miext/sync/misync.c - os/connection.c - os/ospoll.c - os/utils.c - os/xsha1.c - randr/rroutput.c - render/picture.c - xkb/xkb.c - xkb/xkbActions.c - xkb/xkbUtils.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/312a25c65c8a918fea2cc77abd0db07ec0fc421c...38efdcada1609139cb6673e1a4d0ebc8a96306f0 -- View it on GitLab: https://salsa.debian.org/xorg-team/xserver/xorg-server/-/compare/312a25c65c8a918fea2cc77abd0db07ec0fc421c...38efdcada1609139cb6673e1a4d0ebc8a96306f0 You're receiving this email because of your account on salsa.debian.org.
