The `DisableDevice()` function is called whenever an enabled device
is disabled and it moves the device from the `inputInfo.devices` linked
list to the `inputInfo.off_devices` linked list.
However, its link/unlink operation has an issue during the recursive
call to `DisableDevice()` due to the `prev` pointer pointing to a
removed device.
This issue leads to a length mismatch between the total number of
devices and the number of device in the list, leading to a heap
overflow and, possibly, to local privilege escalation.
Simplify the code that checked whether the device passed to
`DisableDevice()` was in `inputInfo.devices` or not and find the
previous device after the recursion.
CVE-2024-21886, ZDI-CAN-22840
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
The `XISendDeviceHierarchyEvent()` function allocates space to store up
to `MAXDEVICES` (256) `xXIHierarchyInfo` structures in `info`.
If a device with a given ID was removed and a new device with the same
ID added both in the same operation, the single device ID will lead to
two info structures being written to `info`.
Since this case can occur for every device ID at once, a total of two
times `MAXDEVICES` info structures might be written to the allocation.
To avoid it, once one add/remove master is processed, send out the
device hierarchy event for the current state and continue. That event
thus only ever has exactly one of either added/removed in it (and
optionally slave attached/detached).
CVE-2024-21885, ZDI-CAN-22744
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
There's a racy sequence where a master device may copy the button class
from the slave, without ever initializing numButtons. This leads to a
device with zero buttons but a button class which is invalid.
Let's copy the numButtons value from the source - by definition if we
don't have a button class yet we do not have any other slave devices
with more than this number of buttons anyway.
CVE-2024-0229, ZDI-CAN-22678
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
The previous code only made sense if one considers buttons and keys to
be mutually exclusive on a device. That is not necessarily true, causing
a number of issues.
This function allocates and fills in the number of xEvents we need to
send the device state down the wire. This is split across multiple
32-byte devices including one deviceStateNotify event and optional
deviceKeyStateNotify, deviceButtonStateNotify and (possibly multiple)
deviceValuator events.
The previous behavior would instead compose a sequence
of [state, buttonstate, state, keystate, valuator...]. This is not
protocol correct, and on top of that made the code extremely convoluted.
Fix this by streamlining: add both button and key into the deviceStateNotify
and then append the key state and button state, followed by the
valuators. Finally, the deviceValuator events contain up to 6 valuators
per event but we only ever sent through 3 at a time. Let's double that
troughput.
CVE-2024-0229, ZDI-CAN-22678
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
If a device has both a button class and a key class and numButtons is
zero, we can get an OOB write due to event under-allocation.
This function seems to assume a device has either keys or buttons, not
both. It has two virtually identical code paths, both of which assume
they're applying to the first event in the sequence.
A device with both a key and button class triggered a logic bug - only
one xEvent was allocated but the deviceStateNotify pointer was pushed on
once per type. So effectively this logic code:
int count = 1;
if (button && nbuttons > 32) count++;
if (key && nbuttons > 0) count++;
if (key && nkeys > 32) count++; // this is basically always true
// count is at 2 for our keys + zero button device
ev = alloc(count * sizeof(xEvent));
FixDeviceStateNotify(ev);
if (button)
FixDeviceStateNotify(ev++);
if (key)
FixDeviceStateNotify(ev++); // santa drops into the wrong chimney here
If the device has more than 3 valuators, the OOB is pushed back - we're
off by one so it will happen when the last deviceValuator event is
written instead.
Fix this by allocating the maximum number of events we may allocate.
Note that the current behavior is not protocol-correct anyway, this
patch fixes only the allocation issue.
Note that this issue does not trigger if the device has at least one
button. While the server does not prevent a button class with zero
buttons, it is very unlikely.
CVE-2024-0229, ZDI-CAN-22678
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Both DeviceFocusEvent and the XIQueryPointer reply contain a bit for
each logical button currently down. Since buttons can be arbitrarily mapped
to anything up to 255 make sure we have enough bits for the maximum mapping.
CVE-2023-6816, ZDI-CAN-22664, ZDI-CAN-22665
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Now that we're only building with meson, all the detritus should be
exclusively in the build directory, with the exception of the detritus
left by various editors (and ctags).
This adds a new command line option "-output" to specify on which output
Xwayland should be starting fullscreen when rootful.
That allows to run multiple instances of Xwayland rootful fullscreen on
multiple outputs.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
When putting the (root) window fullscreen, first search for an output
with the specified name, if any.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
At startup, the names of the Wayland outputs are not yet known,
therefore we cannot rely on those when running fullscreen rootful.
Make sure to check the fullscreen state once the Wayland output name
changes.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Add a output name to the xwl_screen.
This is preparation work for fullscreen rootful on a specific output,
no functional change.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Add a convenient function to search for an xwl_output based on its
XRandR name.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
When running rootful, we do not need to apply the output changes, these
are there just to track the names and show up as disconnected in XRandR.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
When running rootful, Xwayland would simply skip the creation of the CRTC
for the "real" outputs.
Instead, create the CRTC regardless of all outputs in rootful mode, but
mark them as disconnected when running rootful.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
The fixed output is called "XWAYLAND0", yet if the compositor does not
support Wayland output names, the "real" output names may collide with
the fixed output name.
Use the same output serial as with the (default) real output names to
avoid reusing the same names.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Use the simpler form `{ 0 }` instead of `{ '\0', }` for the
initialization of the output name buffer.
No functional change.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Move the code which may update the fullscreen state of the rootful
window to a dedicated helper function.
No functional change.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
If there's no available window buffer.
This allows keeping xwl_window_buffer->damage_region empty for a newly
allocated xwl_window_buffer in xwl_window_buffers_get_pixmap, instead
of first populating it in xwl_window_buffer_add_damage_region and then
emptying it again.
Assuming the same number of window buffers, this results in one less
pixmap per toplevel window, saving pixmap storage.
v2:
* Preserve xwl_window_buffer_get_available behaviour (Olivier Fourdan)
v3:
* Leave RegionEmpty call where it was in xwl_window_buffers_get_pixmap,
so it takes effect for a newly allocated struct xwl_window_buffer.
* Consolidate xwl_window_buffer->pixmap assignment in the same place.
Use xwl_window_buffers_dispose instead. The pixmaps will need to be
re-created anyway, so keeping around the xwl_window_buffers doesn't
buy much. And dropping this makes the next commit simpler.
Also fold xwl_window_buffer_destroy_pixmap into its only remaining
caller, xwl_window_buffer_maybe_dispose.
v2: (Olivier Fourdan)
* Fix up indentation in xwl_window_set_window_pixmap
* Leave xwl_window_buffer_destroy_pixmap helper
GetScratchGC can't really fail without a bug elsewhere. Just FatalError
in that case, so we'd get a bug report if it ever happens, instead of
trying to limp along.
It caused an incorrect result of the blend operation.
Use glColorMask to prevent non-1.0 alpha channel values in a depth 32
pixmap backing an effective depth 24 window. For blending operations,
the expectation is that the destination drawable contains valid pixel
values, so the alpha channel should already be 1.0.
Fixes: d1f142891e ("glamor: Ignore destination alpha as necessary for composite operation")
Issue: https://gitlab.gnome.org/GNOME/mutter/-/issues/3104
XTest requests lets the client specify a device ID, only if none
is specified do we fall back to the XTEST special device.
As of commit
aa4074251 input: Add new hook DeviceSendEventsProc for XTEST
regular devices are no longer able to send XTest events because they
have no sendEventsProc set.
This caused issue #1574 and the crash was fixed with commit
e820030de xtest: Check whether there is a sendEventsProc to call
but we still cannot send XTest events through a specific device.
Fix this by defaulting every device to the XTest send function and
punting it to the DDX (i.e. Xwayland) to override the devices as
necessary.
Fixes e820030de2
Fixes aa4074251f
Instead of hardcoded TouchRec/ValuatorRec init the devices with the
matching functions and go from there. This allows us to clean them
up later, removing the various leaks that stop asan from being happy.
These two tests were dependent on each other, the second test relied on
the xtest devices created in the first test. Let's move the bits that
are shared out into the main function instead to illustrate this better.
This lets us add a call to CloseDownDevices() that will remove the leaks
in this set of tests.
Without this, systemd will be used if installed on the system automagically,
which is a problem if the built e.g. Xwayland is going to be used on a non-systemd
machine.
Bug: https://bugs.gentoo.org/908254
Signed-off-by: Sam James <sam@gentoo.org>
Do not create a pipeline for $CI_PIPELINE_SOURCE == 'push' if
$CI_OPEN_MERGE_REQUESTS is set, which means there are open MRs using
the branch as the source.
A clip should represent the area that is covering the current FB associated
with the CRTC. So making sure each input rect covers any area in the FB is
the first thing to do. If that is the case, the size and coordinates should
be adjusted based on the partial area in the FB the each rect covers. The size
elements need to be truncated if the rect's size exceeds FB's for the CRTC.
Then offsets should be applied to coordinates if the CRTC's offsets aren't 0.
And coordinate transposing and inversion are needed in case the rotated image
is assigned to the FB.
Signed-off-by: Dongwon Kim <dongwon.kim@intel.com>
If we remove a master device and specify which other master devices
attached slaves should be returned to, enforce that those two are
indeeed a pointer and a keyboard.
Otherwise we can try to attach the keyboards to pointers and vice versa,
leading to possible crashes later.
xserver fails to generate useable resolutions with 90Hz framerate
panels(encounter the same issue with 3 different 2.5k resolution
panels). All the resolutions shown by xrandr lead to blank screen except
the one written in EDID.
Ville Syrjälä from Intel provides a method to calculate the preferred
clock and refresh rate from the existing resolution table and this
works for the issue.
v2. xf86ModeVRefresh might return 0, need to check it before use it.
v3. reported by Markus on launchpad that the issue is not devided by 0,
it's the "preferred" being accessed unconditionally.
BugLink: https://launchpad.net/bugs/1999852
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1388
Signed-off-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com>
With the potential modeset vs. modifiers issue covered by
commit 899c87af1f ("modesetting: unflip before any setcrtc() calls")
we can safely enable modifiers by default, at least on Intel
hardware where we know that things work properly.
I suppose the one open question is whether everything will work
correctly with wonky multi-GPU setups? I don't have one to test
myself.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
This allows applications to respond to changes of power level
of a monitor, e.g. an application may stop rendering and related
calculations when the monitor is off.
Related bug: https://bugs.freedesktop.org/57120
Signed-off-by: Alexander Volkov <avolkov@astralinux.ru>
José Expósito
Peter Hutterer
Michel Dänzer
Olivier Fourdan
Luke Dashjr
Sam James
Dongwon Kim
Izumi Tsutsui
xurui
Chia-Lin Kao (AceLan)
Ville Syrjälä
Alexander Volkov