When reading requests from the clients, the input buffer might be shared
and used between different clients.
If a given client sends a full request with non-zero bytes to ignore,
the bytes to ignore may still be non-zero even though the request is
full, in which case the buffer could be shared with another client who's
request will not be processed because of those bytes to ignore, leading
to a possible hang of the other client request.
To avoid the issue, make sure we have zero bytes to ignore left in the
input request when sharing the input buffer with another client.
CVE-2025-49178
This issue was discovered by Nils Emmerich <nemmerich@ernw.de> and
reported by Julian Suleder via ERNW Vulnerability Disclosure.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2024>
The handler of XFixesSetClientDisconnectMode does not check the client
request length.
A client could send a shorter request and read data from a former
request.
Fix the issue by checking the request size matches.
CVE-2025-49177
This issue was discovered by Nils Emmerich <nemmerich@ernw.de> and
reported by Julian Suleder via ERNW Vulnerability Disclosure.
Fixes: e167299f6 - xfixes: Add ClientDisconnectMode
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2024>
The BigRequest extension allows requests larger than the 16-bit length
limit.
It uses integers for the request length and checks for the size not to
exceed the maxBigRequestSize limit, but does so after translating the
length to integer by multiplying the given size in bytes by 4.
In doing so, it might overflow the integer size limit before actually
checking for the overflow, defeating the purpose of the test.
To avoid the issue, make sure to check that the request size does not
overflow the maxBigRequestSize limit prior to any conversion.
The caller Dispatch() function however expects the return value to be in
bytes, so we cannot just return the converted value in case of error, as
that would also overflow the integer size.
To preserve the existing API, we use a negative value for the X11 error
code BadLength as the function only return positive values, 0 or -1 and
update the caller Dispatch() function to take that case into account to
return the error code to the offending client.
CVE-2025-49176
This issue was discovered by Nils Emmerich <nemmerich@ernw.de> and
reported by Julian Suleder via ERNW Vulnerability Disclosure.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2024>
Add a github workflow that builds the Xservers on Linux and also
runs build-test of several common drivers against xorg sdk.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This callback only had been added for Xwayland, which is gone now,
so we don't need it anymore. For property filtering (eg. security
extensions), we have PropertyFilterCallback.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It always had it's own lifecycle (not been part of Xorg releases),
doesn't make sense to maintain a competing implementation that we
won't use anyways.
Once that's gone, we can also drop few things in core/dix that had
been added just for xwayland only.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Protect from NULL parameter to %s directive.
See also: https://github.com/X11Libre/xserver/issues/36
Signed-off-by: Herman Semenov <GermanAizek@yandex.ru>
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
this adds dummy pointers in place of removed fields in some structs, only for
SDK headers, to preserve ABI
some of these fix segfaults for nvidia driver, some are preemptive
Signed-off-by: dasha_uwu <dasha@linuxping.win>
in struct _Screen (include/scrnintstr.h) there is a PRIVATE_LAST-sized array,
having another private increases PRIVATE_LAST, the array increases in size,
moving everything below it down. this breaks ABI for nvidia driver
Signed-off-by: dasha_uwu <dasha@linuxping.win>
Fixes this build error on arch linux:
../Xi/exevents.c:1394:26: error: array subscript ‘InternalEvent {aka union _InternalEvent}[0]’ is partly outside array bounds of ‘DeviceEvent[1]’ {aka ‘struct _DeviceEvent[1]’} [-Werror=array-bounds=]
1394 | evtype = GetXI2Type(ev->any.type);
| ^~~~~~~~~~~~~~~~~~~~~~~~
../Xi/exevents.c: In function ‘DeliverEmulatedMotionEvent’:
../Xi/exevents.c:1571:17: note: object ‘motion’ of size 432
1571 | DeviceEvent motion;
|
which happens because of change in build options compared to master and gcc 15.1 in arch. I think this warning (and error) is a bug in gcc.
gcc 15.1 doesn't like when struct DeviceEvent is cast to union InternalEvent.
InternalEvent has a union any type and DeviceEvent type and these have to have a matching structure (for the header part).
When the InternalEvent is used in RetrieveTouchDeliveryData function it access the any field, which accessed the data defined previously in the device_event fields.
This change matches how its done in touch.c TouchEmitTouchEnd for example and it's "more correct",
since we are no longer casting from a smaller struct (DeviceEvent) to a larger struct (InternalEvent) when calling RetrieveTouchDeliveryData.
Signed-off-by: dec05eba <dec05eba@protonmail.com>
* xled change tested with `xset led named "Scroll Lock"`
* modesetting change tested with `xrandr --output DP-1 --gamma 0.5:0.5:0.5`.
Without this fix that command does nothing
* xvmc change tested with `mpv --vo=xv video.mp4`
Of the currently reported issues this fixes#104
Signed-off-by: dec05eba <dec05eba@protonmail.com>
The `buflength` variable doesn't exist anymore, it's `rlength`.
And even if the reply struct might have the same size as XGenericReply,
it's cleaner to let the compiler compute it explicitly, just in case.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It seems xf86bigfont hasn't been compile-tested for long time,
some includes were missing.
Note that fontstruct.h needs to come before libxfont2.h, because X11
headers tend to be not self-consistent :(
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This fixes a regression in 5499a2999 (xkb: let SendDeviceLedFBs() fill buffer instead of writing directly, 2024-07-16).
We need to write the whole buffer, and the updated length has to take
into consideration that `sz` now contains `led_len` so we need to
subtract that or properly calculate the remaining size.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Since Redhat deleted everything related to Xlibre from freedesktop.org,
the driver repos had to be moved to github.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Nvidia has a strange habit of messing with really internal stuff,
so need to add it to the executable's symbol table.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
As long as the wfb module is still a separate shared object, this
function needs to be in the symbol table.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Nvidia has a strange habit of messing with really internal stuff,
so need to add it to the executable's symbol table.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Olivier Fourdan
Enrico Weigelt, metux IT consult
dasha_uwu
Hermann Semenov
stefan11111
Michael Bear
AnasSaeed1
Steven Van Dorp
rendick
cat
dec05eba
EXtremeExploit
Samq64
Thomas Debesse
catfromplan9
Felipe Contreras