The event might be a DeviceEvent allocated on the stack, in
AccessXKeyboardEvent for instance. Fixes out-of-bounds read.
Signed-off-by: Mike Gorse <mgorse@suse.com>
(cherry picked from commit 2ef5ef57bd)
When processing events we operate on InternalEvent pointers. They may
actually refer to a an instance of DeviceEvent, GestureEvent or any
other event that comprises the InternalEvent union. This works well in
practice because we always look into event type before doing anything,
except in the case of copying the event.
*dst_event = *src_event would copy whole InternalEvent event and would
cause out of bounds read in case the pointed to event was not
InternalEvent but e.g. DeviceEvent.
This regression has been introduced in
23a8b62d34.
Fixes https://gitlab.freedesktop.org/xorg/xserver/-/issues/1261
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
(cherry picked from commit 6ef5c05728)
In commit b320ca0 the mask was inadvertently changed from octal 0177 to
hexadecimal 0x177.
Fixes commit b320ca0ffe
Xtest: disallow GenericEvents in XTestSwapFakeInput
Found by Stuart Cassoff
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit bb1711b7fb)
Unlike other elements of the keymap, this pointer was freed but not
reset. On a subsequent XkbGetKbdByName request, the server may access
already freed memory.
CVE-2022-4283, ZDI-CAN-19530
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>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit ccdd431cd8)
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->num_items 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->num_items bytes, i.e. 4GB.
The same bug exists in ProcChangeProperty and ProcXChangeDeviceProperty,
so let's fix that too.
CVE-2022-46344, ZDI-CAN 19405
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>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit 8f454b793e)
Both ProcXChangeDeviceProperty and ProcXIChangeProperty checked the
property for validity but didn't actually return the potential error.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit b8a84cb0f2)
This fixes a use-after-free bug:
When a client first calls ScreenSaverSetAttributes(), a struct
ScreenSaverAttrRec is allocated and added to the client's
resources.
When the same client calls ScreenSaverSetAttributes() again, a new
struct ScreenSaverAttrRec is allocated, replacing the old struct. The
old struct was freed but not removed from the clients resources.
Later, when the client is destroyed the resource system invokes
ScreenSaverFreeAttr and attempts to clean up the already freed struct.
Fix this by letting the resource system free the old attrs instead.
CVE-2022-46343, ZDI-CAN 19404
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>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit 842ca3ccef)
This fixes a use-after-free bug:
When a client first calls XvdiSelectVideoNotify() on a drawable with a
TRUE onoff argument, a struct XvVideoNotifyRec is allocated. This struct
is added twice to the resources:
- as the drawable's XvRTVideoNotifyList. This happens only once per
drawable, subsequent calls append to this list.
- as the client's XvRTVideoNotify. This happens for every client.
The struct keeps the ClientPtr around once it has been added for a
client. The idea, presumably, is that if the client disconnects we can remove
all structs from the drawable's list that match the client (by resetting
the ClientPtr to NULL), but if the drawable is destroyed we can remove
and free the whole list.
However, if the same client then calls XvdiSelectVideoNotify() on the
same drawable with a FALSE onoff argument, only the ClientPtr on the
existing struct was set to NULL. The struct itself remained in the
client's resources.
If the drawable is now destroyed, the resource system invokes
XvdiDestroyVideoNotifyList which frees the whole list for this drawable
- including our struct. This function however does not free the resource
for the client since our ClientPtr is NULL.
Later, when the client is destroyed and the resource system invokes
XvdiDestroyVideoNotify, we unconditionally set the ClientPtr to NULL. On
a struct that has been freed previously. This is generally frowned upon.
Fix this by calling FreeResource() on the second call instead of merely
setting the ClientPtr to NULL. This removes the struct from the client
resources (but not from the list), ensuring that it won't be accessed
again when the client quits.
Note that the assignment tpn->client = NULL; is superfluous since the
XvdiDestroyVideoNotify function will do this anyway. But it's left for
clarity and to match a similar invocation in XvdiSelectPortNotify.
CVE-2022-46342, ZDI-CAN 19400
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>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit b79f32b57c)
The XKB protocol effectively prevents us from ever using keycodes above
255. For buttons it's theoretically possible but realistically too niche
to worry about. For all other passive grabs, the detail must be zero
anyway.
This fixes an OOB write:
ProcXIPassiveUngrabDevice() calls DeletePassiveGrabFromList with a
temporary grab struct which contains tempGrab->detail.exact = stuff->detail.
For matching existing grabs, DeleteDetailFromMask is called with the
stuff->detail value. This function creates a new mask with the one bit
representing stuff->detail cleared.
However, the array size for the new mask is 8 * sizeof(CARD32) bits,
thus any detail above 255 results in an OOB array write.
CVE-2022-46341, ZDI-CAN 19381
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>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit 51eb63b0ee)
XTestSwapFakeInput assumes all events in this request are
sizeof(xEvent) and iterates through these in 32-byte increments.
However, a GenericEvent may be of arbitrary length longer than 32 bytes,
so any GenericEvent in this list would result in subsequent events to be
misparsed.
Additional, the swapped event is written into a stack-allocated struct
xEvent (size 32 bytes). For any GenericEvent longer than 32 bytes,
swapping the event may thus smash the stack like an avocado on toast.
Catch this case early and return BadValue for any GenericEvent.
Which is what would happen in unswapped setups anyway since XTest
doesn't support GenericEvent.
CVE-2022-46340, ZDI-CAN 19265
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>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit b320ca0ffe)
Commit 8a5f3ddb2 ("set tag on our surface") introduced the use of tags
to differentiate our own surfaces, and commit a1d14aa8c ("Clear the
"xwl-window" tag on unrealize") removed the tags before the surfaces are
actually destroyed.
Xwayland would then rely on these tags on the surface to decide whether
to ignore or to process the Wayland event in various places.
However, in doing so, it also checked for the tag on keyboard leave
events.
As a result, if the keyboard leave events is received after the X11
window is unrealized, keyboard_handle_leave() would not queue the
LeaveNotify events for the DIX to proceed, and the key repeat would
kick in and repeat the key event indefinitely.
To avoid the issue, process events regardless of the tag as before
in keyboard_handle_leave().
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Fixes: 8a5f3ddb2 - "xwayland: set tag on our surface"
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1395
Tested-by: Renan Guilherme Lebre Ramos <japareaggae@gmail.com>
Tested-by: Stefan Dirsch <sndirsch@suse.de>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
(cherry picked from commit 459e285573)
Now that we keep the Wayland surface around for longer than the
xwl_window, we might get events for that surface after the X11 window
is unrealized.
Make sure we untag the Wayland surface when the Wayland surface is
delayed, to break the wl_surface/xwl_window relationship, so that events
for that surface are discarded by Xwayland.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Fixes: e37f18ee9 - xwayland: Delay wl_surface destruction
(cherry picked from commit a1d14aa8c5)
That allows to differentiate Xwayland's own surfaces from others.
This is preparation work for optional libdecor support.
v2: Check for surface not being NULL (Jonas Ådahl <jadahl@gmail.com>)
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit 8a5f3ddb2e)
Xwayland uses API such as wl_proxy_set_tag()/wl_proxy_get_tag() which
appeared in Wayland 1.18, but the build system still requires Wayland
1.5 at least.
Bump the Wayland version to match the requirements.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
(cherry picked from commit 395c25f185)
a77d95af61 intended to do this, but the
check for “is this rootless or rootful XWayland” was inverted.
Fixes: a77d95af61 ("xwayland: Prevent Xserver grabs with rootless")
Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit cb33e0d278)
X11 and Wayland requests are unordered, causing a race in the X11 window
and wl_surface association.
To mitigate that race, delay the wl_surface destruction by 1 second,
so that the compositor has time to establish the association before the
wl_surface is destroyed: to see both the wl_surface created and the
WL_SURFACE_ID X11 property set.
This is only a mitigation though, a more robust solution requires a
future dedicated Wayland protocol.
v2: Clean up pending wl_surface destroy on exit as well.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1157
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Suggested-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Tested-by: Joshua Ashton <joshua@froggi.es>
Tested-by: Sterophonick <sterophonick@gmail.com>
See-also: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/163
(cherry picked from commit e37f18ee97)
Because of the design of most Wayland compositors, where the compositor
is both a Wayland server and an X11 window manager, any X11 client
issuing a server grab (i.e. XGrabServer()) can possibly hang the whole
desktop when Xwayland is running rootless.
This can happen with e.g. ImageMagick's import command with mutter.
1. "import" is launched and issues an XServerGrab(),
2. Xwayland restricts access to that "import" X11 client alone,
3. mutter continues to process events until it needs to sync with
Xwayland (there's variability in time before the hang occurs),
4. When mutter does an XSync() (explicitly or implicitly through some
other Xlib call), it will stop waiting for Xwayland to reply,
5. Xwayland waits for the XServerGrab() to be released by import,
6. "import" waits for a user input to release the XServerGrab(),
7. mutter is stuck waiting on Xwayland and does not process input
events...
To prevent this, re-route the GrabServer/UngrabServer requests and
pretend the grab works but actually does nothing at all for all clients
but the X11 window manager (which can still issue X11 server grabs, at
its own risks).
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Closes: https://bugzilla.redhat.com/1914021
(cherry picked from commit a77d95af61)
Despite e957a2e5dd ("dix: Add hybrid full-size/empty-clip mode to
SetRootClip"), I was still seeing all X11 client windows flashing when
the root window size changes with rootless Xwayland (e.g. due to
hotplugging a monitor).
Skipping this code for ROOT_CLIP_INPUT_ONLY fixes the issue for me.
(cherry picked from commit f778b56a74)
_XkbCheckRequestBounds assumes that from..to is at least one byte.
However, request strings can be empty, causing spurious failures in
XkbGetKbdByName calls. To avoid this, before checking bounds make
sure that the length is nonzero.
(cherry picked from commit 79c572fbd3)
Commit c7311654 cached the value of ResourceClientBits(), but that value
depends on the `MaxClients` value set either from the command line or
from the configuration file.
For the latter, a call to ResourceClientBits() is issued before the
configuration file is read, meaning that the cached value is from the
default, not from the maximum number of clients set in the configuration
file.
That obviously causes all sort of issues, including memory corruption
and crashes of the Xserver when reaching the default limit value.
To avoid that issue, also keep the LimitClient value, and recompute the
ilog2() value if that changes, as on startup when the value is set from
the the xorg.conf ServerFlags section.
v2: Drop the `cache == 0` test
Rename cache vars
Fixes: c7311654 - dix: cache ResourceClientBits() value
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1310
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit 2efa6d6595)
GetCountedString did a check for the whole string to be within the
request buffer but not for the initial 2 bytes that contain the length
field. A swapped client could send a malformed request to trigger a
swaps() on those bytes, writing into random memory.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 11beef0b7f)
Each string length field was accessed before checking whether that byte
was actually part of the client request. No real harm here since it
would immediately fail with BadLength anyway, but let's be correct here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 1bb7767f19)
This request accessed &stuff[1] before length-checking everything. The
check was performed afterwards so invalid requests would return
BadLength anyway, but let's do this before we actually access the
memory.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 44ae6f4419)
GetComponentByName returns an allocated string, so let's free that if we
fail somewhere.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 18f91b950e)
Not that it actually matters since the typedef is int32_t anyway, but
this theoretically avoids an erroneous call to wl_fixed_to_double() on
that value.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 354e39eefa)
Pointer scroll events are collected in xwl_seat->pending_pointer_event
as they are received in the pointer_handle_axis and
pointer_handle_axis_discrete callbacks. They are dispatched together as a
single event when pointer_handle_frame is called which "Indicates the end of a
set of events that logically belong together" [1]. This patch also sends an
event with dx=0, dy=0 when pointer_handle_axis_stop is called, which is what
allows XWayland clients to recognise the end of a touchpad scroll.
[1] https://wayland.app/protocols/wayland#wl_pointer:event:frame
Signed-off-by: David Jacewicz <david.jacewicz27@protonmail.com>
Fixes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/926
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1367
(cherry picked from commit e37eeb7af2)
(cherry picked from commit f0b2eeaf2f)
No validation of the various fields on that report were done, so a
malicious client could send a short request that claims it had N
sections, or rows, or keys, and the server would process the request for
N sections, running out of bounds of the actual request data.
Fix this by adding size checks to ensure our data is valid.
ZDI-CAN 16062, CVE-2022-2319.
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 6907b6ea2b)
XKB often uses a FooCheck and Foo function pair, the former is supposed
to check all values in the request and error out on BadLength,
BadValue, etc. The latter is then called once we're confident the values
are good (they may still fail on an individual device, but that's a
different topic).
In the case of XkbSetDeviceInfo, those functions were incorrectly
named, with XkbSetDeviceInfo ending up as the checker function and
XkbSetDeviceInfoCheck as the setter function. As a result, the setter
function was called before the checker function, accessing request
data and modifying device state before we ensured that the data is
valid.
In particular, the setter function relied on values being already
byte-swapped. This in turn could lead to potential OOB memory access.
Fix this by correctly naming the functions and moving the length checks
over to the checker function. These were added in 87c64fc5b0 to the
wrong function, probably due to the incorrect naming.
Fixes ZDI-CAN 16070, CVE-2022-2320.
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Introduced in c06e27b2f6
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit dd8caf39e9)
Most similar loops here use a pointer that advances with each loop
iteration, let's do the same here for consistency.
No functional changes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit f1070c01d6)
The function xwl_output_remove() is called when removing a monitor, but
the actual status of the RandR output does not change.
So, when RRTellChanged() is called from update_screen_size(), it won't
have the output connection status up to date in the RandR event
RROutputChangeNotifyEvent and X11 applications relying on that event
like Qt will fail to emit their signal QGuiApplication::screenRemoved.
To avoid that issue, make sure to mark the RandR output as disconnected
prior to call xwl_output_remove().
Fix commit 204f10c29 ("xwayland: Call RRTellChanged if the RandR configuration may have changed")
Signed-off-by: zhoulei <zhoulei@kylinos.cn>
Signed-off-by: Morose <chenlinxiang@kylinos.cn>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit 2ec7c1680a)
When the pointer leaves an X11 window, and enters a Wayland native
window, Xwayland has no idea about Wayland native windows and may
generate the wrong crossing events to another X11 window instead.
To avoid that issue, Xwayland implements its own XYToWindow() handler to
compare the Wayland focused surface with the X11 window found in the
window tree.
Commit 59ad0e6a ("xwayland: Fix use after free of cursors") changed the
logic in sprite_check_lost_focus() to use IsParent() to compare the
windows, which works when the X11 window is reparented by the window
manager, but fails in the case of an override redirect window.
To fix the issue, also check whether last_xwindow is the window itself.
Signed-off-by: Morose <chenlinxiang@kylinos.cn>
Fixes: 59ad0e6a - xwayland: Fix use after free of cursors
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit 92a00f5221)
libunwind has a function to query whether the cursor points to a signal frame.
Use this to print
1: <signal handler called>
like GDB does, rather than printing something less useful such as
1: /usr/lib/libpthread.so.0 (funlockfile+0x60) [0x7f679838b870]
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
(cherry picked from commit a73641937a)
Xwayland does not change the actual XRANDR setup for real, it just
emulates the resolution changes using viewports in Wayland.
With a single output, if an X11 applications tries to change the CRTC
back to the native mode, RRCrtcSet() will simply ignore the request as
no actual change is induced by this.
Set the property "RANDR Emulation" on all Xwayland outputs to make sure
the optimizations in RRCrtcSet() get skipped and Xwayland can receive
and act upon the client request.
Also make sure we do not allow that property to be changed by X11
clients.
v2: Prevent X11 clients from changing the property value
(Pekka Paalanen <pekka.paalanen@collabora.com>)
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1305
(cherry picked from commit 7b7170ecd6)
When RANDR is emulated as with Xwayland, the actual output configuration
does not change as RANDR is emulated using viewports.
As a result, changes to the CRTC may be skipped, resulting in the
configuration being (wrongly) assumed to be unchanged.
Add a new output property "RANDR Emulation" that the DDX can set to
force RRCrtcSet() to reconfigure the CRTC regardless of the change.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
(cherry picked from commit 0904421f57)
drm_lease_device_handle_released uses the wrong pointer type in the
callback. This will cause crash when compositor removes drm lease device
object.
Fixes: 089e7f98f - Xwayland: implement drm-lease-v1
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: Weng Xuetian <wengxt@gmail.com>
(cherry picked from commit 479c8aae8e)
Even if there's no pending frame callback yet.
Without this, if there was no pending frame callback yet in
xwl_present_queue_vblank, xwl_present_msc_bump would only get called
from xwl_present_timer_callback, resulting in the MSC ticking at ~58
Hertz.
Doing this requires some adjustments elsewhere:
1. xwl_present_reset_timer needs to check for a pending frame callback
as well.
2. xwl_window_create_frame_callback needs to call
xwl_present_reset_timer for all child windows hooked up to
frame_callback_list, to make sure the timer length takes the pending
frame callback into account.
3. xwl_present_flip needs to hook up the window to frame_callback_list
before calling xwl_window_create_frame_callback, for 2. to work.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1309
Fixes: 9b31358c52 ("xwayland: Use frame callbacks for Present vblank events")
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit 9e5a379610)
Without this, xwl_present_reset_timer would call
xwl_present_timer_callback if the timer was originally armed over a
second ago. xwl_present_timer_callback would call xwl_present_msc_bump,
which could end up hooking up the window to
xwl_window->frame_callback_list again. This would lead to use-after-free
in xwl_present_cleanup:
Invalid write of size 8
at 0x42B65C: __xorg_list_del (list.h:183)
by 0x42B693: xorg_list_del (list.h:204)
by 0x42C041: xwl_present_cleanup (xwayland-present.c:354)
by 0x423669: xwl_destroy_window (xwayland-window.c:770)
by 0x4FDDC5: compDestroyWindow (compwindow.c:620)
by 0x5233FB: damageDestroyWindow (damage.c:1590)
by 0x501C5F: DbeDestroyWindow (dbe.c:1326)
by 0x4EF35B: FreeWindowResources (window.c:1018)
by 0x4EF687: DeleteWindow (window.c:1086)
by 0x4E24B3: doFreeResource (resource.c:885)
by 0x4E2ED7: FreeClientResources (resource.c:1151)
by 0x4ACBA4: CloseDownClient (dispatch.c:3546)
Address 0x12f44980 is 144 bytes inside a block of size 160 free'd
at 0x48470E4: free (vg_replace_malloc.c:872)
by 0x423115: xwl_unrealize_window (xwayland-window.c:621)
by 0x4FCDD8: compUnrealizeWindow (compwindow.c:292)
by 0x4F3F5C: UnrealizeTree (window.c:2805)
by 0x4F424B: UnmapWindow (window.c:2863)
by 0x4EF58C: DeleteWindow (window.c:1075)
by 0x4E24B3: doFreeResource (resource.c:885)
by 0x4E2ED7: FreeClientResources (resource.c:1151)
by 0x4ACBA4: CloseDownClient (dispatch.c:3546)
by 0x5E27EE: ClientReady (connection.c:599)
by 0x5E6CB7: ospoll_wait (ospoll.c:657)
by 0x5DE6CD: WaitForSomething (WaitFor.c:208)
Block was alloc'd at
at 0x4849464: calloc (vg_replace_malloc.c:1328)
by 0x4229CE: ensure_surface_for_window (xwayland-window.c:439)
by 0x4231E8: xwl_window_set_window_pixmap (xwayland-window.c:647)
by 0x5232D6: damageSetWindowPixmap (damage.c:1565)
by 0x4FC7BC: compSetPixmapVisitWindow (compwindow.c:129)
by 0x4EDB3F: TraverseTree (window.c:441)
by 0x4FC851: compSetPixmap (compwindow.c:151)
by 0x4F8C1A: compAllocPixmap (compalloc.c:616)
by 0x4FC938: compCheckRedirect (compwindow.c:174)
by 0x4FCD1D: compRealizeWindow (compwindow.c:274)
by 0x4F36EC: RealizeTree (window.c:2606)
by 0x4F39F5: MapWindow (window.c:2683)
Fixes: 288ec0e046 ("xwayland/present: Run fallback timer callback after more than a second")
Tested-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
(cherry picked from commit 102764b683)
When a window is unrealized, Xwayland would destroy the Wayland surface
prior to unrealizing the present window.
xwl_present_flip() will then do a wl_surface_commit() of that surface,
hence causing a use-after-free:
Invalid read of size 8
at 0x49F7FD4: wl_proxy_marshal_array_flags (wayland-client.c:852)
by 0x49F823A: wl_proxy_marshal_flags (wayland-client.c:784)
by 0x42B877: wl_surface_commit (wayland-client-protocol.h:3914)
by 0x42CAA7: xwl_present_flip (xwayland-present.c:717)
by 0x42CD0E: xwl_present_execute (xwayland-present.c:783)
by 0x42C26D: xwl_present_msc_bump (xwayland-present.c:416)
by 0x42C2D1: xwl_present_timer_callback (xwayland-present.c:433)
by 0x42BAC4: xwl_present_reset_timer (xwayland-present.c:149)
by 0x42D1F8: xwl_present_unrealize_window (xwayland-present.c:945)
by 0x4230E2: xwl_unrealize_window (xwayland-window.c:616)
by 0x4FCDD8: compUnrealizeWindow (compwindow.c:292)
by 0x4F3F5C: UnrealizeTree (window.c:2805)
Address 0x1390b8d8 is 24 bytes inside a block of size 80 free'd
at 0x48470E4: free (vg_replace_malloc.c:872)
by 0x49F8029: wl_proxy_destroy_caller_locks (wayland-client.c:523)
by 0x49F8029: wl_proxy_marshal_array_flags (wayland-client.c:861)
by 0x49F823A: wl_proxy_marshal_flags (wayland-client.c:784)
by 0x421984: wl_surface_destroy (wayland-client-protocol.h:3672)
by 0x423052: xwl_unrealize_window (xwayland-window.c:599)
by 0x4FCDD8: compUnrealizeWindow (compwindow.c:292)
by 0x4F3F5C: UnrealizeTree (window.c:2805)
by 0x4F424B: UnmapWindow (window.c:2863)
by 0x4EF58C: DeleteWindow (window.c:1075)
by 0x4E24B3: doFreeResource (resource.c:885)
by 0x4E2ED7: FreeClientResources (resource.c:1151)
by 0x4ACBA4: CloseDownClient (dispatch.c:3546)
Block was alloc'd at
at 0x4849464: calloc (vg_replace_malloc.c:1328)
by 0x49F7F29: zalloc (wayland-private.h:233)
by 0x49F7F29: proxy_create (wayland-client.c:422)
by 0x49F7F29: create_outgoing_proxy (wayland-client.c:664)
by 0x49F7F29: wl_proxy_marshal_array_flags (wayland-client.c:831)
by 0x49F823A: wl_proxy_marshal_flags (wayland-client.c:784)
by 0x4218CA: wl_compositor_create_surface (wayland-client-protocol.h:1291)
by 0x422A0D: ensure_surface_for_window (xwayland-window.c:445)
by 0x4231E8: xwl_window_set_window_pixmap (xwayland-window.c:647)
by 0x5232D6: damageSetWindowPixmap (damage.c:1565)
by 0x4FC7BC: compSetPixmapVisitWindow (compwindow.c:129)
by 0x4EDB3F: TraverseTree (window.c:441)
by 0x4FC851: compSetPixmap (compwindow.c:151)
by 0x4F8C1A: compAllocPixmap (compalloc.c:616)
by 0x4FC938: compCheckRedirect (compwindow.c:174)
To avoid that, call xwl_present_unrealize_window() before destroying the
Wayland surface.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
(cherry picked from commit 42113ab289)
The composite overlay window (COW) can be queried from any X11 client,
not just the X11 compositing manager.
If a client tries to get the composite overlay window, the Xserver will
map the window and block all pointer events (the window being mapped and
on top of the stack).
To avoid that issue, unset the "mapped" state of the composite overlay
window once realized when Xwayland is running rootless.
Note: All Xservers are actually affected by this issue, but with most
regular X servers, the compositing manager will take care of dealing
with the composite overlay window, and an X11 client using
GetOverlayWindow() won't break pointer events for all X11 clients.
Wayland compositors however usually run Xwayland rootless and have no
use for the COW.
v2: Avoid registering damage for the COW (Michel)
v3: Remove the "mapped" test to avoid calling register_damage() if the
COW is not mapped (Michel)
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1314
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
(cherry picked from commit 47d3317464)
