- Dec 13, 2023
-
-
Peter Hutterer authored
Signed-off-by:
Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
button->xkb_acts is supposed to be an array sufficiently large for all our buttons, not just a single XkbActions struct. Allocating insufficient memory here means when we memcpy() later in XkbSetDeviceInfo we write into memory that wasn't ours to begin with, leading to the usual security ooopsiedaisies. CVE-2023-6377, ZDI-CAN-22412, ZDI-CAN-22413 This vulnerability was discovered by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative (cherry picked from commit 0c1a93d3)
-
Peter Hutterer authored
Affected are ProcRRChangeProviderProperty and ProcRRChangeOutputProperty. See also 8f454b79 where this same bug was fixed for the core protocol and XI. This fixes an OOB read and the resulting information disclosure. Length calculation for the request was clipped to a 32-bit integer. With the correct stuff->nUnits value the expected request size was truncated, passing the REQUEST_FIXED_SIZE check. The server then proceeded with reading at least stuff->num_items bytes (depending on stuff->format) from the request and stuffing whatever it finds into the property. In the process it would also allocate at least stuff->nUnits bytes, i.e. 4GB. CVE-2023-6478, ZDI-CAN-22561 This vulnerability was discovered by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative (cherry picked from commit 14f48001)
-
- Dec 04, 2023
-
-
Olivier Fourdan authored
When creating the output with the default "XWAYLAND<n>" name, we use the MAX_OUTPUT_NAME value to allocate a lot more memory than necessary to accommodate for future output names once they get updated, but by doing so, we also send XRandR way too much (zeroed) data since the "nameLength" value is (purposely) set too big. So, instead, let's just update the name after creating the RR output, this way we set both the name and nameLength to their correct values while keeping the initial large allocation. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Fixes: 3c07a01c - xwayland: Use xdg-output name for XRandR Reviewed-by:
Simon Ser <contact@emersion.fr> (cherry picked from commit 83453fb5)
-
Olivier Fourdan authored
At creation, Xwayland uses a generic output name ("XWAYLAND0", etc.) for the XRandR outputs, and later, once the name is known from the Wayland protocols, updates the output names using the actual names from the Wayland compositor. However, when doing so, it simply updates the string, the "nameLength" isn't updated, so the name passed to the clients might either end up being truncated or contain portions of the previous (initial) output name. Note, this is using a fixed size buffer initialized with zeros, so this cannot leak any data other than the previous output name, so this is mainly a cosmetic issue. Update the output's "nameLength" when updating the output name. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Fixes: 3c07a01c - xwayland: Use xdg-output name for XRandR Reviewed-by:
Simon Ser <contact@emersion.fr> (cherry picked from commit 0e314afe)
-
- Nov 29, 2023
-
-
Olivier Fourdan authored
Most X servers, even those which do not have specific configuration files, can use the directory specified by SERVER_MISC_CONFIG_PATH when they have either the XSECURITY or XSELINUX extensions enabled, or when support for DTRACE is enabled at build time, because this is also where the "protocol.txt" file is searched for at runtime. Unfortunately, the SERVER_MISC_CONFIG_PATH is set from serverconfigdir which is hardcoded in the build system to "$prefix/$libdir/xorg", and all X server builds share the same path. That makes it harder for different X servers such as Xwayland to install in the same path without sharing the same server configuration path (and hence the same "protocol.txt" file). Allow for the customization of server configuration path from the build options so that different X servers can use completely different and independent paths. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 411a61f5)
-
Olivier Fourdan authored
When running fullscreen, if an X11 client has changed the resolution, Xwayland is using a viewport to emulate the expected resolution. When changing focus, the Wayland compositor will send a configure event with the actual surface size, not the size of the emulated XRandR resolution. As a result, changing focus while XRandR emulation (and hence the viewport) is active in Xwayland will revert the resolution to the actual output size, defeating the XRandR emulation. To avoid that issue, only change the size when not running fullscreen. Fixes: 53b6d4db - xwayland: Apply root toplevel configure dimensions Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Kenny Levinsen <kl@kl.wtf> (cherry picked from commit a797776f)
-
Olivier Fourdan authored
Make sure to update the fullscreen rootful window configuration whenever the output setup changes. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Kenny Levinsen <kl@kl.wtf> (cherry picked from commit 06eb7271)
-
Olivier Fourdan authored
Whenever the output configuration changes, if Xwayland is running fullscreen, we may need to update the viewport in use or even update the output on which Xwayland is currently running fullscreen. Add a new helper function xwl_window_rootful_update_fullscreen() that will recompute the fullscreen state and the viewport setup so that the fullscreen Xwayland rootful window matches the new setup. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Kenny Levinsen <kl@kl.wtf> (cherry picked from commit 73b9ff53)
-
Olivier Fourdan authored
No functional change. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Kenny Levinsen <kl@kl.wtf> (cherry picked from commit 2f84e3fe)
-
- Oct 25, 2023
-
-
Peter Hutterer authored
Signed-off-by:
Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
The handling of appending/prepending properties was incorrect, with at least two bugs: the property length was set to the length of the new part only, i.e. appending or prepending N elements to a property with P existing elements always resulted in the property having N elements instead of N + P. Second, when pre-pending a value to a property, the offset for the old values was incorrect, leaving the new property with potentially uninitalized values and/or resulting in OOB memory writes. For example, prepending a 3 element value to a 5 element property would result in this 8 value array: [N, N, N, ?, ?, P, P, P ] P, P ^OOB write The XI2 code is a copy/paste of the RandR code, so the bug exists in both. CVE-2023-5367, ZDI-CAN-22153 This vulnerability was discovered by: Jan-Niklas Sohn working with Trend Micro Zero Day Initiative Signed-off-by:
Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 541ab2ec)
-
- Oct 24, 2023
-
-
This is more portable than libbsd as everything Just Works, even on BSD systems, and is the recommended method of consuming libbsd nowadays. It also helpfully lets things work with glibc-provided functions for new enough glibc. Closes: xorg/xserver!973 Co-authored-by:
Guillem Jover <guillem@hadrons.org> Signed-off-by:
Sam James <sam@gentoo.org> (cherry picked from commit 94945a52)
-
- Oct 12, 2023
-
-
Olivier Fourdan authored
Xwayland maintains a connection to EI up for 10 minutes after an X11 client has vanished, to avoid going through the connection phase every time a short lived X11 client comes and goes. However, if the EI client gets freed (through some other event, e.g. the user decides to terminate the EI session), Xwayland would still keep the callback alive and end up trying to free an already freed EI client: Invalid read of size 4 at 0x4C5E6F9: object_unref (util-object.h:89) by 0x4C5E6F9: ei_unref (libei.c:77) by 0x429525: free_ei (xwayland-xtest.c:224) by 0x429A6E: disconnect_timer_cb (xwayland-xtest.c:404) by 0x5E63FF: DoTimer (WaitFor.c:276) by 0x5E6463: DoTimers (WaitFor.c:290) by 0x5E6164: check_timers (WaitFor.c:133) by 0x5E61E9: WaitForSomething (WaitFor.c:195) by 0x4AD50E: Dispatch (dispatch.c:487) by 0x4BBA0B: dix_main (main.c:272) by 0x43615D: main (stubmain.c:34) Address 0x15cc6ee8 is 8 bytes inside a block of size 240 free'd at 0x48452AC: free (vg_replace_malloc.c:974) by 0x4C5E729: object_destroy (util-object.h:73) by 0x4C5E729: object_unref (util-object.h:91) by 0x4C5E729: ei_unref (libei.c:77) by 0x429525: free_ei (xwayland-xtest.c:224) by 0x42A946: xwl_handle_ei_event (xwayland-xtest.c:804) by 0x5EA977: HandleNotifyFd (connection.c:809) by 0x5EE8E3: ospoll_wait (ospoll.c:657) by 0x5E624D: WaitForSomething (WaitFor.c:208) by 0x4AD50E: Dispatch (dispatch.c:487) by 0x4BBA0B: dix_main (main.c:272) by 0x43615D: main (stubmain.c:34) Block was alloc'd at at 0x484782C: calloc (vg_replace_malloc.c:1554) by 0x4C5E777: ei_create (libei.c:73) by 0x4C5E777: ei_create_context (libei.c:97) by 0x42994B: setup_ei (xwayland-xtest.c:366) by 0x42A383: xwayland_xtest_send_events (xwayland-xtest.c:658) by 0x54ED4C: ProcXTestFakeInput (xtest.c:441) by 0x54EE56: ProcXTestDispatch (xtest.c:475) by 0x4AD6E6: Dispatch (dispatch.c:546) by 0x4BBA0B: dix_main (main.c:272) by 0x43615D: main (stubmain.c:34) To avoid that issue, make sure to cancel the timer as soon as a EI client is freed. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Peter Hutterer <peter.hutterer@who-t.net> See-also: https://bugzilla.redhat.com/2243076 (cherry picked from commit 9617de73)
-
NV12 only has 2 planes. Signed-off-by:
Jeffy Chen <jeffy.chen@rock-chips.com> (cherry picked from commit 0076671e)
-
Olivier Fourdan authored
If we fail to setup EI, give up on using EI for XTEST and restore the default XTEST handlers. This happens when neither the portal nor the socket backends are usable. This does not affect the portal operation though, if the user choose not to allow a particular client, Xwayland would continue to use EI. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Joshua Ashton <joshua@froggi.es> (cherry picked from commit 6b56ae68)
-
Olivier Fourdan authored
With EI support wired to XTEST, and oeffis being enabled unconditionally means that Xwayland will always go through the XDG portal for XTEST when supported. While this the intended behavior for the general use case of Xwayland running rootless on a desktop compositor, that breaks when Xwayland is running on a nested compositor, because the portal is for the entire session and not limited to the nested Wayland compositor. Xwayland itself, as a regular Wayland client, has no way to tell that it is running on a nested compositor. So to keep backward compatibility with existing (and also common) use cases such as nested compositors, best is to disable support for the XDG portal by default, and add a new command line option "-enable-ei-portal" for the Wayland compositors (who spawn Xwayland rootless) to explicitly enable support for the input emulation XDG portal in Xwayland. A Wayland compositor running nested should not use that command line option with Xwayland. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Joshua Ashton <joshua@froggi.es> Fixes: a1333342 - xwayland: Add XTEST support using EIS Closes: xorg/xserver#1586 See-also: https://gitlab.gnome.org/GNOME/mutter/-/issues/3047 (cherry picked from commit cfcbb075)
-
Some drivers might not support explicit format modifiers. On these drivers `gbm_bo_create_with_modifiers()` will fail and the `gbm_bo_create()` code path will be used instead. In this case, if the LINEAR modifier is advertised (and the INVALID modifier is not) add the `GBM_BO_USE_LINEAR` flag. Closes: xorg/xserver#1438 Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com> Signed-off-by:
José Expósito's avatarJosé Expósito <jexposit@redhat.com> (cherry picked from commit 287638db)
-
If there is no quads to draw, then we have a possibility to call glDrawElements with type as zero, which will generate GL_INVALID_ENUM error. While this error is harmless, it is annoying. Signed-off-by:
Konstantin <ria.freelander@gmail.com> Reviewed-by:
Adam Jackson <ajax@redhat.com> (cherry picked from commit baaddf47)
-
- Sep 20, 2023
-
-
Olivier Fourdan authored
Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com>
-
- Sep 19, 2023
-
-
Olivier Fourdan authored
If a client tries to send XTEST events while there is no sendEventsProc defined for the given device, Xwayland would call into 0x0 and crash. Make sure the handler is defined before trying to use it, to avoid the crash. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Peter Hutterer <peter.hutterer@who-t.net> Closes: #1574 (cherry picked from commit e820030d)
- Aug 16, 2023
-
-
Olivier Fourdan authored
Xwayland 23.2.0 final release Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com>
-
We specify a sensible default geometry for decorated rootful windows, but not for undecorated ones. Make the default geometry apply to rootful windows in general. Signed-off-by:
Kenny Levinsen <kl@kl.wtf> (cherry picked from commit 8128a215)
-
While we now have support for resize of the root window through libdecor, we still ignore toplevel configure dimensions when libdecor is not in use. This ignores user intent in many Wayland servers, and some xdg_toplevel states when active have strong requirements for adherence to configure dimensions. Resize in response to xdg_toplevel configure dimensions like we do for libdecor configure events. Signed-off-by:
Kenny Levinsen <kl@kl.wtf> (cherry picked from commit 53b6d4db)
-
The upcoming handling of plain xdg_toplevel.configure events will need to use the xwl_window resize helper. Move it outside XWL_HAS_LIBDECOR, move the remaining dimension logic from handle_libdecor_configure into it and update the name accordingly. Signed-off-by:
Kenny Levinsen <kl@kl.wtf> (cherry picked from commit 4f869c6e)
-
- Aug 11, 2023
-
-
When handling libdecor configure, we first update our xwl output and screen if dimensions differ from the current xwl_screen, and then commit a new libdecor frame which acknowledges the xdg_surface.configure event. If the initial configure events contains non-zero dimensions, we will update the xwl output before acknowledging the initial configure. As we attach a buffer and commit the surface when updating the output, this leads to a protocol error. Instead, move the surface commit till the end of the configure handler so it always happens after the ack. Signed-off-by:
Kenny Levinsen <kl@kl.wtf> (cherry picked from commit 295fb716)
-
- Aug 02, 2023
-
-
Olivier Fourdan authored
Xwayland 23.2.0 release candidate 2. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com>
-
- Jul 27, 2023
-
-
Olivier Fourdan authored
Similar to commit 94deed27 - " xwayland: Use sensible defaults for rootful size", mark fullscreen mode as fixed so that the actual monitor layout is not reflected in the single fullscreen rootful window. Without this, if "-fullscreen" is used without "-geometry", the XRandR configuration is taken from the compositor via wl_output/xdg-output and cannot be changed by the X11 clients. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com> (cherry picked from commit 34446a99)
-
Olivier Fourdan authored
Enforce sensible min/max values for the window size when using libdecor. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com> (cherry picked from commit 881e1a56)
-
Olivier Fourdan authored
This is to avoid repeating the same code in two places. This is essentially a cosmetic change, not a functional change. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com> (cherry picked from commit f19fe9d2)
-
Olivier Fourdan authored
Allow passing an optional libdecor configuration pointer to xwl_window_update_libdecor_size() so that we can reuse it from more than one place and avoid duplicating that code. No functional change. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com> (cherry picked from commit c180eca8)
-
Olivier Fourdan authored
The configure handler in libdecor is triggered any time a new configuration is received. According to the documentation from libdecor, an application should respond to that event by creating a suitable libdecor_state, and apply it using libdecor_frame_commit(). So we ought to attach a new buffer matching the new size and commit the Wayland surface. The actual content of the window does not need to be explicitly repainted, that occurs through the call to SetRootClip(): xwl_output_set_mode_fixed() -> update_screen_size() -> SetRootClip() -> miHandleValidateExposures() -> miWindowExposures() -> miPaintWindow() This fixes an issue with mutter where maximizing a window and then switching to another window would sometimes resize the Xwayland window back to its pre-maximized size, or with Weston where the Xwayland window would initially show up black until the pointer moves to the window. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com> (cherry picked from commit 6d00c2bc)
-
Olivier Fourdan authored
This moves the code which updates the XRandR modes and sets the root window size to its own function. This preparation work for the next commit, no functional change. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com> (cherry picked from commit e37539e1)
-
Olivier Fourdan authored
The configure handler for libdecor, namely handle_libdecor_configure(), is where both the content and the decorations get resized (when needed). If for any reason, the actual size of the Xwayland screen fails to be updated, we would still appy the expected size rather than the actual one for the libdecor state. To avoid this, use the actual xwl_screen width/height for the libdecor state. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com> (cherry picked from commit cda004c2)
-
Olivier Fourdan authored
For libdecor, we will have to attach a new buffer and commit from two different handlers (libdecor configure and commit). Having xwl_window_attach_buffer() separate from xwl_window_post_damage() is to allow for that. This commit should not introduce any functional change. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com> Reviewed-by:
Michel Dänzer <mdaenzer@redhat.com> (cherry picked from commit 8bbd908d)
-
glamor ensures that a depth 32 pixmap backing a depth 24 window contains fully opaque alpha channel values for the window's pixels, so we can allow this without implicit redirection, saving pixmap storage and intermediate copies. Second attempt, after fixing a few regressions from the first attempt. (cherry picked from commit 4bb1f976)
-
Instead of a PixmapPtr. Gives better results if the window depth doesn't match the backing pixmap depth. Closes: xorg/xserver#1565 (cherry picked from commit d4e11f4c)
-
See also the previous commit log. Fixes the issues with xterm & xcalc described in the GitLab issue below. Issue: xorg/xserver#1564 (cherry picked from commit 2de50de5)
-