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 <jeremyhu@apple.com>
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 <jeremyhu@apple.com>
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.
Fixes [2/2]: https://github.com/XQuartz/XQuartz/issues/323
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
The glyph bounding box in RootlessGlyphs is computed in
drawable-relative (window-local) coordinates, but RootlessDamageBox
expects global (screen) coordinates. Without translating by
drawable.x/y, the damage region often fell outside the window's
borderClip and was silently discarded by RootlessDamageRegion.
RootlessGlyphs accumulated glyph positions starting from (xSrc, ySrc)
instead of (0, 0). The xSrc/ySrc parameters are the source picture
reference point, not destination offsets. Every standard Glyphs
implementation (fbGlyphs, miGlyphs) starts position accumulation
from (0, 0) and builds up destination coordinates by adding each
GlyphList's xOff/yOff deltas.
Starting from xSrc shifted the entire damage bounding box by
(xSrc, ySrc), causing it to miss the actual rendered region. For
typical text rendering where xSrc equals the destination x position,
this doubled the offset, placing the damage box well outside the
window's borderClip and causing RootlessDamageRegion to silently
discard it.
Fixes [1/2]: https://github.com/XQuartz/XQuartz/issues/323
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Failure to do so causes an overvlow in RRClientCallback().
=================================================================
==41262==ERROR: AddressSanitizer: global-buffer-overflow on address 0x000103ccfbc8 at pc 0x0001034f32b9 bp 0x7000035a94c0 sp 0x7000035a94b8
WRITE of size 4 at 0x000103ccfbc8 thread T6
#0 0x1034f32b8 in RRClientCallback randr.c:72
#1 0x1038c75e3 in _CallCallbacks dixutils.c:737
#2 0x10388f406 in CallCallbacks callback.h:83
#3 0x1038bc49a in NextAvailableClient dispatch.c:3562
#4 0x103ad094c in AllocNewConnection connection.c:777
#5 0x103ad1695 in EstablishNewConnections connection.c:863
#6 0x1038c6630 in ProcessWorkQueue dixutils.c:523
#7 0x103ab2dbf in WaitForSomething WaitFor.c:175
#8 0x103880836 in Dispatch dispatch.c:411
#9 0x1038c2141 in dix_main main.c:301
#10 0x1032ac75a in server_thread quartzStartup.c:66
#11 0x7fffc5f16aaa in _pthread_body (libsystem_pthread.dylib+0x3aaa)
#12 0x7fffc5f169f6 in _pthread_start (libsystem_pthread.dylib+0x39f6)
#13 0x7fffc5f161fc in thread_start (libsystem_pthread.dylib+0x31fc)
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
(cherry picked from commit f9235000d67a61b0de951598146b4b5e0032384e)
Failure to do so causes an overvlow in glxClientCallback
Application Specific Information:
X.Org X Server 1.18.99.1 Build Date: 20160911
=================================================================
==52118==ERROR: AddressSanitizer: SEGV on unknown address 0x000102b27b80 (pc 0x000103433245 bp 0x70000de67c20 sp 0x70000de67c00 T6)
#0 0x103433244 in __asan::asan_free(void*, __sanitizer::BufferedStackTrace*, __asan::AllocType) (libclang_rt.asan_osx_dynamic.dylib+0x3244)
#1 0x10347aeee in wrap_free (libclang_rt.asan_osx_dynamic.dylib+0x4aeee)
#2 0x102e6a5ed in glxClientCallback glxext.c:301
#3 0x102b672a3 in _CallCallbacks dixutils.c:737
#4 0x102b2f0c6 in CallCallbacks callback.h:83
#5 0x102b5c15a in NextAvailableClient dispatch.c:3562
#6 0x102d7060c in AllocNewConnection connection.c:777
#7 0x102d71355 in EstablishNewConnections connection.c:863
#8 0x102b662f0 in ProcessWorkQueue dixutils.c:523
#9 0x102d52a7f in WaitForSomething WaitFor.c:175
#10 0x102b204f6 in Dispatch dispatch.c:411
#11 0x102b61e01 in dix_main main.c:301
#12 0x10254c42a in server_thread quartzStartup.c:66
#13 0x7fffc5f16aaa in _pthread_body (libsystem_pthread.dylib+0x3aaa)
#14 0x7fffc5f169f6 in _pthread_start (libsystem_pthread.dylib+0x39f6)
#15 0x7fffc5f161fc in thread_start (libsystem_pthread.dylib+0x31fc)
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
(cherry picked from commit 1d2293101fca46c9a68c553f1be8e815c40de69a)
This updates rootless to treat pixmaps consistently with COMPOSITE,
using the screen_x and screen_y values rather than doing hacky math.
This will allow for proper bounds checking on a given PixmapRec.
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
This should no longer be necessary since we only support implementations
that handle preserving the bits across resize. We can use
RootlessNoCopyWindow instead.
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
This should no longer be necessary since we only support implementations that handle preserving the bits across resize
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
I don't see a reason why we would want to preserve pixels that are going to
not be visible anyways. The rootless implementation already handles
preserving the relevant bits for us.
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
If none of the four corners is fixed, we can use RL_GRAVITY_NORTH_WEST weighting
for the operation to let the implementation presetve the window bits for us.
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
The implementation owns the pointer during RootlessStopDrawing and
RootlessStartDrawing and is free to (does) change it. Rootless
cannot assume ownership of this memory region. This is possibly
the cause of some hard to diagnose crashes in XQuartz over the
years.
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
This reverts commit 0a1ee643b2.
This is causing a number of regressions on existing setups:
* Reverse PRIME with the NVIDIA proprietary driver, where software
rendering is used instead of the NVIDIA GLX library with hardware
acceleration
* Performance issues with AMDGPU
* Rendering with 10-bit output with AMDGPU
Revert the change that is causing these regressions in the stable branch.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1848
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2104>
The script comes from a backport where only meson is used and therefore
the new files were omitted from the Makefile.
As a result, these files are not included in the released tar file and
the build fails.
Fixes: 95b899118 - meson: add glamor gles2 tests
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2089>
The XkbCompatMap structure stores its "num_si" and "size_si" fields
using an unsigned short.
However, the function _XkbSetCompatMap() will store the sum of the
input data "firstSI" and "nSI" in both XkbCompatMap's "num_si" and
"size_si" without first checking if the sum overflows the maximum
unsigned short value, leading to a possible overflow.
To avoid the issue, check whether the sum does not exceed the maximum
unsigned short value, or return a "BadValue" error otherwise.
CVE-2025-62231, ZDI-CAN-27560
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
(cherry picked from commit 475d9f49ac)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2087>
XkbRemoveResourceClient() would free the XkbInterest data associated
with the device, but not the resource associated with it.
As a result, when the client terminates, the resource delete function
gets called and accesses already freed memory:
| Invalid read of size 8
| at 0x5BC0C0: XkbRemoveResourceClient (xkbEvents.c:1047)
| by 0x5B3391: XkbClientGone (xkb.c:7094)
| by 0x4DF138: doFreeResource (resource.c:890)
| by 0x4DFB50: FreeClientResources (resource.c:1156)
| by 0x4A9A59: CloseDownClient (dispatch.c:3550)
| by 0x5E0A53: ClientReady (connection.c:601)
| by 0x5E4FEF: ospoll_wait (ospoll.c:657)
| by 0x5DC834: WaitForSomething (WaitFor.c:206)
| by 0x4A1BA5: Dispatch (dispatch.c:491)
| by 0x4B0070: dix_main (main.c:277)
| by 0x4285E7: main (stubmain.c:34)
| Address 0x1893e278 is 184 bytes inside a block of size 928 free'd
| at 0x4842E43: free (vg_replace_malloc.c:989)
| by 0x49C1A6: CloseDevice (devices.c:1067)
| by 0x49C522: CloseOneDevice (devices.c:1193)
| by 0x49C6E4: RemoveDevice (devices.c:1244)
| by 0x5873D4: remove_master (xichangehierarchy.c:348)
| by 0x587921: ProcXIChangeHierarchy (xichangehierarchy.c:504)
| by 0x579BF1: ProcIDispatch (extinit.c:390)
| by 0x4A1D85: Dispatch (dispatch.c:551)
| by 0x4B0070: dix_main (main.c:277)
| by 0x4285E7: main (stubmain.c:34)
| Block was alloc'd at
| at 0x48473F3: calloc (vg_replace_malloc.c:1675)
| by 0x49A118: AddInputDevice (devices.c:262)
| by 0x4A0E58: AllocDevicePair (devices.c:2846)
| by 0x5866EE: add_master (xichangehierarchy.c:153)
| by 0x5878C2: ProcXIChangeHierarchy (xichangehierarchy.c:493)
| by 0x579BF1: ProcIDispatch (extinit.c:390)
| by 0x4A1D85: Dispatch (dispatch.c:551)
| by 0x4B0070: dix_main (main.c:277)
| by 0x4285E7: main (stubmain.c:34)
To avoid that issue, make sure to free the resources when freeing the
device XkbInterest data.
CVE-2025-62230, ZDI-CAN-27545
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
(cherry picked from commit 10c94238bd)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2087>
Currently, the resource in only available to the xkb.c source file.
In preparation for the next commit, to be able to free the resources
from XkbRemoveResourceClient(), make that variable private instead.
This is related to:
CVE-2025-62230, ZDI-CAN-27545
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
(cherry picked from commit 99790a2c92)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2087>
Using the Present extension, if an error occurs while processing and
adding the notifications after presenting a pixmap, the function
present_create_notifies() will clean up and remove the notifications
it added.
However, there are two different code paths that can lead to an error
creating the notify, one being before the notify is being added to the
list, and another one after the notify is added.
When the error occurs before it's been added, it removes the elements up
to the last added element, instead of the actual number of elements
which were added.
As a result, in case of error, as with an invalid window for example, it
leaves a dangling pointer to the last element, leading to a use after
free case later:
| Invalid write of size 8
| at 0x5361D5: present_clear_window_notifies (present_notify.c:42)
| by 0x534A56: present_destroy_window (present_screen.c:107)
| by 0x41E441: xwl_destroy_window (xwayland-window.c:1959)
| by 0x4F9EC9: compDestroyWindow (compwindow.c:622)
| by 0x51EAC4: damageDestroyWindow (damage.c:1592)
| by 0x4FDC29: DbeDestroyWindow (dbe.c:1291)
| by 0x4EAC55: FreeWindowResources (window.c:1023)
| by 0x4EAF59: DeleteWindow (window.c:1091)
| by 0x4DE59A: doFreeResource (resource.c:890)
| by 0x4DEFB2: FreeClientResources (resource.c:1156)
| by 0x4A9AFB: CloseDownClient (dispatch.c:3567)
| by 0x5DCC78: ClientReady (connection.c:603)
| Address 0x16126200 is 16 bytes inside a block of size 2,048 free'd
| at 0x4841E43: free (vg_replace_malloc.c:989)
| by 0x5363DD: present_destroy_notifies (present_notify.c:111)
| by 0x53638D: present_create_notifies (present_notify.c:100)
| by 0x5368E9: proc_present_pixmap_common (present_request.c:164)
| by 0x536A7D: proc_present_pixmap (present_request.c:189)
| by 0x536FA9: proc_present_dispatch (present_request.c:337)
| by 0x4A1E4E: Dispatch (dispatch.c:561)
| by 0x4B00F1: dix_main (main.c:284)
| by 0x42879D: main (stubmain.c:34)
| Block was alloc'd at
| at 0x48463F3: calloc (vg_replace_malloc.c:1675)
| by 0x5362A1: present_create_notifies (present_notify.c:81)
| by 0x5368E9: proc_present_pixmap_common (present_request.c:164)
| by 0x536A7D: proc_present_pixmap (present_request.c:189)
| by 0x536FA9: proc_present_dispatch (present_request.c:337)
| by 0x4A1E4E: Dispatch (dispatch.c:561)
| by 0x4B00F1: dix_main (main.c:284)
| by 0x42879D: main (stubmain.c:34)
To fix the issue, count and remove the actual number of notify elements
added in case of error.
CVE-2025-62229, ZDI-CAN-27238
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit 5a4286b13f)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2087>
Reported in #1817:
xwayland-24.1.6/redhat-linux-build/../dix/property.c:584:5:
warning[-Wanalyzer-malloc-leak]: leak of ‘pAtoms’
Can happen if, and only if, XaceHookPropertyAccess() blocks access
to all properties, so that numProps ends up zero on the second loop.
Fixes: 39f337fd4 ("dix: ProcListProperties: skip unneeded work if numProps is 0")
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
(cherry picked from commit ed92eae84d)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2077>
If we're swapping 4-byte integers or 2-byte integers, make sure the size
of the buffer doesn't have any bytes left over, since we won't correctly
handle those bytes.
Reported in #1817:
xwayland-24.1.6/redhat-linux-build/../dix/swaprep.c:99:22:
warning[-Wanalyzer-allocation-size]:
allocated buffer size is not a multiple of the pointee's size
xwayland-24.1.6/redhat-linux-build/../dix/swaprep.c:146:22:
warning[-Wanalyzer-allocation-size]:
allocated buffer size is not a multiple of the pointee's size
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
(cherry picked from commit cf49354b60)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2077>
The wOtherInputMasks(win) macro will return NULL if
win->optional is NULL.
Reported in #1817:
xwayland-24.1.6/redhat-linux-build/../dix/gestures.c:242:9:
warning[-Wanalyzer-null-dereference]: dereference of NULL ‘inputMasks’
xwayland-24.1.6/redhat-linux-build/../dix/touch.c:765:9:
warning[-Wanalyzer-null-dereference]: dereference of NULL ‘inputMasks’
xwayland-24.1.6/redhat-linux-build/../dix/touch.c:782:9:
warning[-Wanalyzer-null-dereference]: dereference of NULL ‘inputMasks’
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
(cherry picked from commit 15496a5e3d)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2077>
Reported in #1817:
xwayland-24.1.6/redhat-linux-build/../Xi/xibarriers.c:729:5:
warning[-Wanalyzer-null-dereference]:
dereference of NULL ‘AllocBarrierDevice()’
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
(cherry picked from commit 0ee6039053)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2077>
Reported in #1817:
xwayland-24.1.6/redhat-linux-build/../Xi/listdev.c:171:5:
warning[-Wanalyzer-possible-null-dereference]:
dereference of possibly-NULL ‘dev’
xwayland-24.1.6/redhat-linux-build/../Xi/listdev.c:379:23:
acquire_memory: this call could return NULL
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
(cherry picked from commit 19c6195e71)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2077>
Reported in #1817:
xwayland-24.1.6/redhat-linux-build/../Xi/getprop.c:163:25:
warning[-Wanalyzer-possible-null-dereference]:
dereference of possibly-NULL ‘buf’
xwayland-24.1.6/redhat-linux-build/../Xi/getprop.c:121:19:
acquire_memory: this call could return NULL
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
(cherry picked from commit 7b18313e2a)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2077>
(The existing setting of led_mask is probably wrong, but has been set
like this since X11R5 and going back as far as the first version in
the X Consortium source control archives.)
Reported in #1817:
xwayland-24.1.6/redhat-linux-build/../Xi/getfctl.c:108:9:
warning[-Wanalyzer-use-of-uninitialized-value]:
use of uninitialized value ‘*k2.led_values’
108|-> swapl(&k2->led_values);
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
(cherry picked from commit 90c8429d35)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2077>
The wOtherInputMasks(win) macro will return NULL if
win->optional is NULL.
Reported in #1817:
xwayland-24.1.6/redhat-linux-build/../Xi/exevents.c:1390:13:
warning[-Wanalyzer-null-dereference]: dereference of NULL ‘0’
xwayland-24.1.6/redhat-linux-build/../Xi/exevents.c:1404:13:
warning[-Wanalyzer-null-dereference]: dereference of NULL ‘0’
xwayland-24.1.6/redhat-linux-build/../Xi/exevents.c:2293:9:
warning[-Wanalyzer-null-dereference]: dereference of NULL ‘0’
xwayland-24.1.6/redhat-linux-build/../Xi/exevents.c:3244:22:
warning[-Wanalyzer-null-dereference]: dereference of NULL ‘inputMasks’
xwayland-24.1.6/redhat-linux-build/../Xi/exevents.c:3338:9:
warning[-Wanalyzer-null-dereference]: dereference of NULL ‘0’
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
(cherry picked from commit 7b7bcf9231)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2077>
If there's nothing to send, skip over a bunch of code to make a list
that won't be used, and hopefully make the code path clearer to both
humans and static analyzers, who raise errors as seen in #1817 of
dereferencing NULL pointers when count == 0.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
(cherry picked from commit d34243606c)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2077>
Reported in #1817:
xwayland-24.1.6/redhat-linux-build/../Xext/xres.c:233:13: warning[-Wanalyzer-possible-null-dereference]: dereference of possibly-NULL ‘current_clients’
xwayland-24.1.6/redhat-linux-build/../Xext/xres.c:228:23: acquire_memory: this call could return NULL
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
(cherry picked from commit 3da60c96a9)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2077>
Reported in #1817:
xwayland-24.1.6/redhat-linux-build/../Xext/vidmode.c:96:5: warning[-Wanalyzer-null-argument]: use of NULL ‘VidModeCreateMode()’ where non-null expected
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
(cherry picked from commit 5e62aaaf57)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2077>
Reported incorrectly in #1817 as:
xwayland-24.1.6/redhat-linux-build/../Xext/sync.c:2835:33: acquire_memory: allocated here
xwayland-24.1.6/redhat-linux-build/../Xext/sync.c:2843:12: danger: ‘priv’ leaks here; was allocated at [(30)](sarif:/runs/0/results/5/codeFlows/0/threadFlows/0/locations/29)
but the "leak" is really saving the pointer in an uninitalized pointer in
a structure that was already freed when the malloc of the SysCounterInfo
struct failed in SyncCreateSystemCounter(), because it returned the address
of the freed struct instead of NULL to indicate failure.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
(cherry picked from commit 6034ce11b6)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2077>
