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/2088>
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/2088>
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/2088>
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/2088>
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/2076>
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/2076>
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/2076>
InputOnly windows aren't relevant here.
E.g. mutter-x11-frames uses GTK4, which creates a 1x1 InputOnly child
window, which previously prevented this code from working as intended.
v2: (Olivier Fourdan)
* Rename output_child -> input_output_child.
* Add comment in get_single_input_output_child explaining why we return
NULL if input_output_child is already non-NULL.
(cherry picked from commit 6f31791945)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2076>
If the WM client reparents a window, mark the new parent as a WM window.
This helps with current mutter, where decoration windows are created by
a separate mutter-x11-frames client instead of the WM client. There
might be other compositors doing something similar now or in the future.
v2:
* Skip the whole unwrap-and-call-down dance in xwl_reparent_window if
xwl_screen->ReparentWindow is NULL.
(cherry picked from commit 105b5f2402)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2076>
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/2076>
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/2076>
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/2076>
(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/2076>
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/2076>
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/2076>
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/2076>
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/2076>
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/2076>
glamor_sync.c calls miSyncShmScreenInit if HAVE_XSHMFENCE is defined,
but it was only being built if either dri3 or xwayland were enabled.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
(cherry picked from commit a8f8ec7e7d)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2076>
In the doListFontsWithInfo function in dixfonts.c, when a font alias is
encountered (err == FontNameAlias), the code saves the current state
and allocates memory for c->savedName.
If the malloc(namelen + 1) call fails, c->savedName remains NULL,
but c->haveSaved is still set to TRUE. Later, when a font is
successfully resolved (err == Successful), the code uses c->savedName
without checking if it is NULL, so there is potential null ptr
dereference. XNFalloc will check result of malloc and stop
program execution if allocation was failed.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1842
Signed-off-by: Mikhail Dmitrichenko <m.dmitrichenko222@gmail.com>
(cherry picked from commit dd5c2595a4)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2076>
The LogVHdrMessageVerb function may access an array out of bounds in a
specific edge case. Specifically, the line:
newline = (buf[len - 1] == '\n');
can result in accessing buf[-1] if len == 0, which is undefined behavior.
Commit adds check to avoid access out of bounds at pointed line.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1841
Signed-off-by: Mikhail Dmitrichenko <m.dmitrichenko222@gmail.com>
(cherry picked from commit 8d25a89143)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2076>
Commit d36f66f15d ("Check for duplicate output names") would walk the
list of existing outputs and leases to check that no other existing
output has the same name.
The change however, inadvertently reused the regular screen outputs when
searching the leased names.
Fix this by using the lease name, not the regular output names that we
already checked just above.
Found by SAST tool Svace.
Fixes: d36f66f15d - xwayland: Check for duplicate output names
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1843
Reviewed-by Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Mikhail Dmitrichenko <m.dmitrichenko222@gmail.com>
(cherry picked from commit b096785df4)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2076>
Commit 54f8fc4090 introduced the use of
wl_surface::set_buffer_scale, which is only available starting with
version 3 of the wl_compositor protocol. Because we already prefer
version 4 when available, this went unnoticed but broke versions 1, 2
and 3 when reaching the wl_surface::set_buffer_scale call.
This restores functionality for version 3 and properly document that
versions 1 and 2 are not supported anymore.
Signed-off-by: Nicolas Guichard <nicolas.guichard@kdab.com>
(cherry picked from commit bcc0587ab9)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2076>
The commit referenced below partially resolved an issue with grabs being made
on the root window. Unfortunately it assumes that the application uses
the same client for all windows. VMware Workstation uses nested windows
for each VM, each of which runs its own process with this own client.
Theses windows are managed by the GUI which is the top level for the
application and maps the windows based on which tab is selected.
Because the VM windows issue a grab on the root window and don't share
the same client as the GUI, grabs don't work properly with global shortcut
inhibition being completely broken.
Getting the parent top-level of the nested windows fixes this issue.
Fixes: c7730cfe55 ("xwayland: Translate keyboard grabs on the root window")
Signed-off-by: Ian Forbes <ian.forbes@broadcom.com>
(cherry picked from commit afc8b781d8)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2076>
Consider the following keymap:
```xkb
xkb_keymap {
xkb_keycodes {
<compose> = 135;
};
xkb_symbols {
key <compose> {
[ SetGroup(group = +1) ]
};
};
};
```
When the user presses the compose key, the following happens:
1. The compositor forwards the key to Xwayland.
2. Xwayland executes the SetGroup action and sets the base_group to 1
and the effective group to 1.
3. The compositor updates its own state and sends the effective group,
1, to Xwayland.
4. Xwayland sets the locked group to 1 and the effective group to
1 + 1 = 2.
This is wrong since pressing compose should set the effective group to 1
but to X applications the effective group appears to be 2.
This commit makes it so that Xwayland completely ignores the key
behaviors and actions of the keymap and only updates the modifier and
group components in response to the wayland modifiers events.
Signed-off-by: Julian Orth <ju.orth@gmail.com>
(cherry picked from commit 45c1d22ff6)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2060>
The EXT_blend_func_extended extension on ESSL always requires explicit
request to allow two FS out variables because of limitations of the ESSL
language, which is mentioned as the No.6 issue of the extension's
specification.
Fix this by adding the extension request.
The original behavior on GLES3 is slightly against the specification of
GL_EXT_blend_func_extended extension, however Mesa and older version of
PowerVR closed drivers will just ignore this issue. Newest PowerVR
closed driver will bail out on this problem, so it deems a fix now.
Fixes: ee107cd491 ("glamor: support GLES3 shaders")
Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
(cherry picked from commit eba15f1ba7)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2041>
Xwayland dispatches tablet tool tip events immediately when they arrive.
With compositors such as mutter and sway, it is not an issue because
their libinput backends synthetize axis events before tip events. In
other words, axis data and the tip status belong to different frames.
On the other hand, kwin sends axis and tip events in a single frame
(its libinput backend generates a single tip event with axis data
attached to it). Since the tip events are dispatched immediately,
they can have wrong information associated with them, for example tool
position or pressure. It results in undesired "streaks" when the user
presses the tablet tool against the tablet.
See also https://bugs.kde.org/show_bug.cgi?id=479856.
Signed-off-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>
(cherry picked from commit 60f0bfe852)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2041>
When changing the RandR provider property, if the property does not
already exists, it is created.
In case of error, however, it doesn't get freed, leading to a leak of
the allocated property.
Make sure to free the RandR property in case of error if was to be
added.
Found by OpenScanHub.
Fixes: 3c3a4b767 - randr: Check for overflow in RRChangeProviderProperty()
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit c34f59ee15)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2041>
Check for another possible integer overflow once we get a complete xReq
with BigRequest.
Related to CVE-2025-49176
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Suggested-by: Peter Harris <pharris2@rocketsoftware.com>
(cherry picked from commit 4fc4d76b2c)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2030>
A client might send a request causing an integer overflow when computing
the total size to allocate in RRChangeProviderProperty().
To avoid the issue, check that total length in bytes won't exceed the
maximum integer value.
CVE-2025-49180
This issue was discovered by Nils Emmerich <nemmerich@ernw.de> and
reported by Julian Suleder via ERNW Vulnerability Disclosure.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 3c3a4b767b)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2026>
The RecordSanityCheckRegisterClients() checks for the request length,
but does not check for integer overflow.
A client might send a very large value for either the number of clients
or the number of protocol ranges that will cause an integer overflow in
the request length computation, defeating the check for request length.
To avoid the issue, explicitly check the number of clients against the
limit of clients (which is much lower than an maximum integer value) and
the number of protocol ranges (multiplied by the record length) do not
exceed the maximum integer value.
This way, we ensure that the final computation for the request length
will not overflow the maximum integer limit.
CVE-2025-49179
This issue was discovered by Nils Emmerich <nemmerich@ernw.de> and
reported by Julian Suleder via ERNW Vulnerability Disclosure.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 2bde9ca49a)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2026>
When reading requests from the clients, the input buffer might be shared
and used between different clients.
If a given client sends a full request with non-zero bytes to ignore,
the bytes to ignore may still be non-zero even though the request is
full, in which case the buffer could be shared with another client who's
request will not be processed because of those bytes to ignore, leading
to a possible hang of the other client request.
To avoid the issue, make sure we have zero bytes to ignore left in the
input request when sharing the input buffer with another client.
CVE-2025-49178
This issue was discovered by Nils Emmerich <nemmerich@ernw.de> and
reported by Julian Suleder via ERNW Vulnerability Disclosure.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit d55c54cecb)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2026>
The handler of XFixesSetClientDisconnectMode does not check the client
request length.
A client could send a shorter request and read data from a former
request.
Fix the issue by checking the request size matches.
CVE-2025-49177
This issue was discovered by Nils Emmerich <nemmerich@ernw.de> and
reported by Julian Suleder via ERNW Vulnerability Disclosure.
Fixes: e167299f6 - xfixes: Add ClientDisconnectMode
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit ab02fb96b1)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2026>
The BigRequest extension allows requests larger than the 16-bit length
limit.
It uses integers for the request length and checks for the size not to
exceed the maxBigRequestSize limit, but does so after translating the
length to integer by multiplying the given size in bytes by 4.
In doing so, it might overflow the integer size limit before actually
checking for the overflow, defeating the purpose of the test.
To avoid the issue, make sure to check that the request size does not
overflow the maxBigRequestSize limit prior to any conversion.
The caller Dispatch() function however expects the return value to be in
bytes, so we cannot just return the converted value in case of error, as
that would also overflow the integer size.
To preserve the existing API, we use a negative value for the X11 error
code BadLength as the function only return positive values, 0 or -1 and
update the caller Dispatch() function to take that case into account to
return the error code to the offending client.
CVE-2025-49176
This issue was discovered by Nils Emmerich <nemmerich@ernw.de> and
reported by Julian Suleder via ERNW Vulnerability Disclosure.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
(cherry picked from commit 03731b326a)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2026>
Animated cursors use a series of cursors that the client can set.
By default, the Xserver assumes at least one cursor is specified
while a client may actually pass no cursor at all.
That causes an out-of-bound read creating the animated cursor and a
crash of the Xserver:
| Invalid read of size 8
| at 0x5323F4: AnimCursorCreate (animcur.c:325)
| by 0x52D4C5: ProcRenderCreateAnimCursor (render.c:1817)
| by 0x52DC80: ProcRenderDispatch (render.c:1999)
| by 0x4A1E9D: Dispatch (dispatch.c:560)
| by 0x4B0169: dix_main (main.c:284)
| by 0x4287F5: main (stubmain.c:34)
| Address 0x59aa010 is 0 bytes after a block of size 0 alloc'd
| at 0x48468D3: reallocarray (vg_replace_malloc.c:1803)
| by 0x52D3DA: ProcRenderCreateAnimCursor (render.c:1802)
| by 0x52DC80: ProcRenderDispatch (render.c:1999)
| by 0x4A1E9D: Dispatch (dispatch.c:560)
| by 0x4B0169: dix_main (main.c:284)
| by 0x4287F5: main (stubmain.c:34)
|
| Invalid read of size 2
| at 0x5323F7: AnimCursorCreate (animcur.c:325)
| by 0x52D4C5: ProcRenderCreateAnimCursor (render.c:1817)
| by 0x52DC80: ProcRenderDispatch (render.c:1999)
| by 0x4A1E9D: Dispatch (dispatch.c:560)
| by 0x4B0169: dix_main (main.c:284)
| by 0x4287F5: main (stubmain.c:34)
| Address 0x8 is not stack'd, malloc'd or (recently) free'd
To avoid the issue, check the number of cursors specified and return a
BadValue error in both the proc handler (early) and the animated cursor
creation (as this is a public function) if there is 0 or less cursor.
CVE-2025-49175
This issue was discovered by Nils Emmerich <nemmerich@ernw.de> and
reported by Julian Suleder via ERNW Vulnerability Disclosure.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: José Expósito <jexposit@redhat.com>
(cherry picked from commit 0885e0b262)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2026>
This fixes a crash when we try to send focus events and dereference
FollowKeyboardWin (0x3) as WindowPtr.
A device set to XSetDeviceFocus(FollowKeyboard) is supposed to follow
the focus of the corresponding master device. During ActivateKeyboard
a slave device is detached from the master for the duration for the grab
so we don't actually have a master to follow - leaving our oldWin set to
the FollowKeyboardWin constant. This later crashes when we try to
dereference it.
Fix this by getting the current master (if any), or the saved master (if
temporarily detached due to a grab). And if failing that, use the VCK
as fallback device - that is technically wrong but it's such a niche use
case that it shouldn't matter.
Reproducer:
window = XCreateSimpleWindow(...)
deviceid = any device that is IsXExtensionKeyboard device
XSetDeviceFocus(deviceid, FollowKeyboard, ...)
XGrabDevice(deviceid, window, ...)
Fixes: f01ee198ff ("dix: don't use inputInfo.keyboard to get the focus window in ActivateKbdGrab")
Found-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Tested-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit cab9017485)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1895>
