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>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2086>
Yet another very internal function that the proprietary Nvidia driver
is using for unknown reasons. NVidia really needs a separate function
for just for some trivial struct initialization and don't manage to
add three simple lines to their code, so we have to make an extra
function for them.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Yet another very internal function that the proprietary Nvidia driver
is using for unknown reasons.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The private struct is pretty small and it needs to be allocated anyways,
so save an extra allocation by directly embedding it.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Only used inside shm.c, not anywhere else, so no need to keep it
in a public header file.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Document some non-trivial aspects and add warnings what not to
touch in order to not breaking ABI.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for patching up the request buffer anymore - just pass in the correct
value directly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
On certain setups, it might still be useful to force a particular cursor
size via xorg.conf.
For example, if on a system the automatic probes fail, or if the user wants
a particular cursor size, that is higher that the minimum size.
Signed-off-by: stefan11111 <stefan11111@shitposting.expert>
On most cards, SIZE_HINTS isn't available.
Without this, most users would have to set the fallback cursor size themselves,
or rely on the 64x64 default.
Signed-off-by: stefan11111 <stefan11111@shitposting.expert>
Since it's now doing nothing more than unhooking itself, we really
don't need it anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The wOtherInputMasks(win) macro will return NULL if
win->optional is NULL.
Reported in https://gitlab.freedesktop.org/xorg/xserver/-/issues/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>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2075>
Reported incorrectly in https://gitlab.freedesktop.org/xorg/xserver/-/issues/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>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2072>
Instead of having a pointer to a struct just consisting of a pointer,
just move that struct directly into the privates area, so we not just
save one extra indirection, but also not having to care about an extra
chunk of malloc'ed memory anymore (thus getting rid of a potential
OOM bug)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
For cpu_family(), meson returns "sparc" for 32-bit sparc,
and "sparc64" for 64-bit sparc, regardless of the OS in use.
For cpu(), meson returns values like "sun4v" on Solaris/SPARC,
and doesn't promise stability of the values, or portability across
OS'es, unlike cpu_family().
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2070>
