The LogVHdrMessageVerb function may access an array out of bounds in a
specific edge case. Specifically, the line:
newline = (buf[len - 1] == '\n');
can result in accessing buf[-1] if len == 0, which is undefined behavior.
Commit adds check to avoid access out of bounds at pointed line.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1841
Signed-off-by: Mikhail Dmitrichenko <m.dmitrichenko222@gmail.com>
(cherry picked from commit 8d25a89143)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2076>
Check for another possible integer overflow once we get a complete xReq
with BigRequest.
Related to CVE-2025-49176
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Suggested-by: Peter Harris <pharris2@rocketsoftware.com>
(cherry picked from commit 4fc4d76b2c)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2030>
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>
(cherry picked from commit d55c54cecb)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2026>
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>
(cherry picked from commit 03731b326a)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2026>
The comment at the top of the function tells humans the fallthroughs
are intentional, but gcc doesn't parse that.
Clears 3 -Wimplicit-fallthrough warnings from gcc 14.1
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
(cherry picked from commit b306df5a60)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1766>
struct hostent->h_addr_list is of type char**, not const char**.
GCC considers this an error when in C99 mode or later.
Signed-off-by: Joaquim Monteiro <joaquim.monteiro@protonmail.com>
(cherry picked from commit 0ddcd87851)
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1635>
fix warning:
> ../os/rpcauth.c:159:16: warning: result of comparison of constant -1 with expression of type 'XID' (aka 'unsigned int') is always false [-Wtautological-constant-out-of-range-compare]
> if (rpc_id == ~0L)
> ~~~~~~ ^ ~~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1431>
These functions are just used for reading auth file or calling xkbcomp while
dropping privileges, in case the Xserver is started as unprivileged user
with suid-root. Thus, shouldn't be used (and aren't used) by drivers.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1370>
This function isn't used by any driver and doesn't seem to be useful for them,
thus move it out of the public module API, in order to tidy it up a bit.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1366>
osdep.h needs Bool type, which is defined X11/Xdefs.h.
For now it works, since Xdefs usually is already included somewhere
else, but that's an unreliable programming styles which quickly hits
us when changing include order.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1366>
This conditional practically only controls whether we have an pointer,
where DDX can plug in it's own VErrorF() handler (currently only xwin
doing that). The cost of having it even when DDX doesn't use it, is
really negligible: it's just one pointer and an extra non-null check
on it per VErrorF() call - a very cold path. Strangely, xwin has extra
Getting rid of this unnecessary complexity that really hasn't any
practical gain.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1329>
This header is never exported and belongs to OS layer, thus no need to have it
in include/ directory, where all the public ones are - better off under os/.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1350>
These functions aren't used by and drivers (and TimerInit() shouldn't be
be called from modules at all), thus unexport them.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1330>
* this symbol is a server configuration flag (can be passed via cmdline)
for limiting the max size of big-requests. there shouldn't be any need
to use it outside the core X server (in server modules like drivers
or external extension) - therefore unexport it
* in order to reduce namespace pollution of public (server module API)
headers, create a new internal header for those tings (more to come)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1275>
The symbols HAVE_SIGACTION and BUSFAULT are set under the same conditions,
so can be consolidated into one. Also define dummies when HAVE_SIGACTION
is not set, so a few #ifdef's less clutterig the code.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1297>
This breaks the xf86-input-synaptics driver:
synaptics.c: In function 'clickpad_guess_clickfingers':
synaptics.c:2638:5: error: implicit declaration of function 'BUG_RETURN_VAL' [-Werror=implicit-function-declaration]
2638 | BUG_RETURN_VAL(hw->num_mt_mask > sizeof(close_point) * 8, 0);
This reverts commit 442aec2219.
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1316>
The workQueue pointer is currently declared extern, so that WaitForSomething()
can check wether we've got something in the queue and call ProcessWorkQueue()
then.
But that's trivial to simplify: just let ProcessWorkQueue() return early if
workQueue == NULL. Gives us a better isolation of internal stuff as well as
ProcessWorkQueue() protecting itself from possible segfault.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1310>
The generic auth handling isn't really OS specific, and only few sites
actually need to call it, so at least it's prototypes are better off in some
separate header.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1311>
The MIT authentication handling isn't really OS specific, and only few sites
actually need to call it, so at least it's prototypes are better off in some
separate header.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1311>
The xdmcp authentication handling isn't really OS specific, and only few sites
actually need to call it, so at least it's prototypes are better off in some
separate header.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1311>
The xdmcp handling isn't really OS specific, and only few sites actually need
to call it, so at least it's prototypes are better off in some separate header.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1311>
The rpc authentication handling isn't really OS specific, and only few sites
actually need to call it, so at least it's prototypes are better off in some
separate header.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1311>
The old approach of builtin color lookup used a binary search of strings
within text blocks (their start offsets defined in the color array).
This could potentially lead to buffer overflow, if the requested color
name far outreaches the text block (eg. same prefix as some entry near to
the end, but really huge). This alone wouldn't allow remote memory readout
(just comparing), but could possibly trigger page faults (sigsegv) or used
as a building block for some more complex attack.
OTOH, the old approach is also hard to maintain, ugly programming style:
on each change, all the offset need to be carefully recounted, which is
pretty error-prone.
Both problems are solved by moving to simple, per-entry, char* pointers,
instead of the one large text block.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1313>
The "name" field doesn't actually hold the color's name, but instead the
offset of the name in the string table block. Thus, fix the field's name
to reflect this.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1313>
