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>
Call DeleteCallbackList(&pScreen->hookPostCreateResources) during
dixFreeScreen, because otherwise it will be heap-use-after-free during
DeleteCallbackManager call.
Signed-off-by: Tautvis <gtautvis@gmail.com>
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>
Removing the namespace assignment of killed clients in ClientState-hook
is too early - we still need it later. Using the new ClientDestroyCallback
instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Existing client-state hook isn't sufficient for this, and so easy to
be extended cleanly (*1). Adding a new callback is trivial and cheap,
so preferring this way, instead of trying to tweak the existing hook
for something it's never been designed for.
*1) see discussion here: https://github.com/X11Libre/xserver/pull/1077
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
f.d.o is failing too often in recent times, so switching to our
own mirrors at github.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Fix pedantic warnings:
> ../include/os.h:144:71: warning: ISO C does not allow extra ‘;’ outside of a function [-Wpedantic]
> 144 | XNFalloc(unsigned long /*amount */ ) __attribute__((returns_nonnull));;
> ../include/os.h:158:76: warning: ISO C does not allow extra ‘;’ outside of a function [-Wpedantic]
> 158 | XNFcallocarray(size_t nmemb, size_t size) __attribute__((returns_nonnull));;
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Now that the test suite has been fixed to work on the CI, we no longer
need (and should) ignore broken test runs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
MacOS build suddenly missing xvfb-run, which did work up until few hours ago.
Therefore, make a quick workaround, until the situation is clearly resolved.
The only impact is that some XTS tests (which are ignored on MacOS anyways)
might not work properly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Make sure the release message won't be created when build jobs on the
release tag didn't succeed.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The GLES tests need an actual GPU (/dev/dri/* device), which is not available
within github CI runners, so we need to skip those when running there.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
We need to run the Xts build inside Xvfb, because it needs a running
Xserver for creating tetexec.cfg.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Run various common checking commands like xdpyinfo, xvinfo, etc
on both Xvfb directly, as well as Xephyr inside Xvfb.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The triangles test of rendercheck is known to be (partially broken on Xephyr,
since it doesn't fully support transparency (eg. a8 surfaces).
Therefore make it optional, so we're not spammed too much by false alarms
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Several sites we need to clone our dependencies from (eg. freedesktop.org)
have pretty unreliable servers, so our CI jobs often fail just because
of temporary clone failure.
Therefore adding a separate cloning script, which is more clever with automatic
retries, but it also tries to keep the traffic low (eg. trying shallow clones
if possible) and automatically detecting whether we're pulling a ref or a
direct commit.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Also store the piglit results into the build artifacts, so we can now
easily look at them later.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
We've been adding the individual sub-packet's payload bytes *after*
the swapping, which is leading to totally wrong sizes.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The namespace config still has the "container" directive, which should have
been named "namespace". It's a leftover from the original working draft that
was named "container extension".
For the time being, keep backwards compatibility by allowing both tokens
"container" as well as "namespace" for the same directive. But consider the
old token as deprecated, it shouldn't be used anymore and might go away
in the near future.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The 2nd loop is supposed to free the privates and also clear the pointer
to them. But it instead of clearing the walk'ed pointer, it only clears
the one in the last screen left from the upper loop.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
On WIN32 we need to include winsock2.h, but we can't include misc.h here
becaues it pulling in X11 headers that are conflicting with win32 headers.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
These defines are already public, used by consumers of SetNotifyFd(),
but also needed in places where os.h cannot be included.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The request struct's length fields aren't used anymore - we have the
client->req_len field instead, which also is bigreq-compatible.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Low level OS specific code should not depend on higher level protocol
headers. This also removes yet another conflict with win32/mingw headers.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>